为何前端构建工具这么麻烦

2021-08-09 15:53:04 +08:00
 weimo383
被 webpack 整晕的一天。想问问后端构建工具是不是很方便🌚🌚
15920 次点击
所在节点    程序员
119 条回复
mrouyoung
2021-08-11 10:07:45 +08:00
最近学习 webpack,单独从零不用任何脚手架的话 配一个 React 项目需要配好多东西,很多配置项虽然官网有描述但是实际因为看不到体现在哪里就很费解,所以很多配置项不知道该不该配。

这里想提个问,我看公司里项目配完 eslint,写好配置文件,vscode 提示报错而且 ctrl+s 保存时自动修复格式错误,自己单独用 webpack 配的项目, .eslint 文件配置项跟公司项目一致,但就愣是不起作用,ctrl+s 保存也不自动修复格式。

网上查资料都说 vscode 设置一下保存自动修复类似 auto fix to save 这种设置项。但我一寻思我起的公司项目和刚单独配的项目 vscode 的设置应该都是一样的,为何还会有这种差异。

~才学这个勿喷。有大佬解答一手没。
orsa
2021-08-11 10:28:25 +08:00
@mrouyoung 自动修复格式是 prettier 做的工作,eslint 只管提示报错
lneoi
2021-08-11 10:52:28 +08:00
现在生成项目基本都会携带默认的配置, 不需要特别定制化的话, 实际上不用研究的很深入
完全自己生成一个项目, 在 github 也有很多配置好的通用模板可以参考
lifespy
2021-08-11 11:06:45 +08:00
mrouyoung
2021-08-11 11:14:59 +08:00
@orsa prettier 也配过了,webpack 中 eslint 模块也加载过了,关键 eslint 也没报错,所以 prettier 不起作用
ipwx
2021-08-11 11:38:32 +08:00
其实吧,总结一下就是:前端的课还没补完。

----

对比一下 C++

上古时代的 C/C++ 也是很麻烦的。从单文件的 compiler / loader,进化到 make + Makefile,进化到 autoconf / automake,再进化到 CMake 之类的。CMake 几乎已成为事实上比较通用的 C++ 构建工具了,但是还没有完全统治地位。当年 boost 有自己的 bjam,Google 有自己的 bazel,等等不一而足。

到目前为止裸 CMake 配起来也挺麻烦的。不过 conan.io 之类的基于 CMake 的包管理器进一步简化了配置,基本上标准系统上零配置就能用 conan + CMake 拉一堆 C++ 的库开始撸代码。

----

对比一下 Java / PHP / C#,无一不是有这个过程。Java 的 Maven,PHP 的 Composer,C# 的 Nuget,一开始也都是没有的。只不过 Java / PHP / C# 相对更容易统一环境,所以它们走的比 C++ 远。

前端现阶段不好用,只不过是因为太新了所以没有角逐出统一的工具链而已。
ZxBing0066
2021-08-11 12:05:33 +08:00
@pabupa 面对固定场景 那就不要选择 webpack,而去选择封装好的 cra 、vue-cli 这些东西,而这些底层都是 webpack,只是针对 lz 提问解释为什么这么复杂而已
bnm965321
2021-08-11 13:05:16 +08:00
@abcbuzhiming npm 作为包管理器来说是先进的,你的逻辑是错误的,不能说作者觉得有瑕疵就不代表它在同时代有先进性。我觉得他比同时代的 pip 好用很多,后来的 cargo 也收到了 npm 的影响
seakingii
2021-08-11 13:16:33 +08:00
前端构建确实不爽,现在 VUE 的作者搞的 VITE 就是想超越 WEBPACK,可以试试 VITE
abcbuzhiming
2021-08-11 13:56:02 +08:00
@bnm965321 作者用词可不是瑕疵,用的是“错误”和“困境”。你觉得你比作者更理解 npm ?

我也不想和你争论这个,没意义,我们互相不可能说服对方的,我能理解有些 noder 对 node 唯一一个包管理器 npm 的维护情绪。但我本身是多门语言一路玩过来的,我更喜欢批判而不是维护。我也不打算去说服别人,你的存在恰好证明了我的观点,前端社区对什么是好,什么不好,根本不统一,社区意见都不统一,工具链发展自然是左右摇摆的探索期
gimp
2021-08-11 14:20:23 +08:00
@abcbuzhiming #110 npm 确实难用的,安装几个依赖拖家带口几百 M
lin07hui
2021-08-11 14:34:50 +08:00
虽然 webpack 存在我的每个项目,但我基本都不直接接触 webpack,有小手架呀。
列车 Deno 号进站,要上车的抓紧咯
chenmobuys
2021-08-11 14:46:24 +08:00
npm 的依赖实在是太大了,随随便便都能上 G,Java,Php 的依赖到了 100M 都已经算是很大了。
chenmobuys
2021-08-11 14:47:09 +08:00
node 原作者自己不想继续维护了。
dothis
2021-08-11 16:13:09 +08:00
@killerv 我特么要被你笑死了
bnm965321
2021-08-11 17:24:02 +08:00
@abcbuzhiming 错误也分整体错误还是局部错误。你可以举几个 npm 同时间段存在的其它的包管理器做做例子,然后看看之后出现的包管理器有没有 npm 的影子
zhwithsweet
2021-08-11 17:55:50 +08:00
来,写个 Vue 组件库,撸一遍就知道,不难。
模板在此: https://github.com/zouhangwithsweet/vuecomponent-seed

vite + esbuild + ts-morph
catbestme
2021-08-11 18:16:08 +08:00
@qrobot
你那说的只是理论骨架,实际的 webpack 配置是互相嵌套,互相引用,关系错综复杂,感觉非常混乱,用起来非常恶心
newmlp
2021-08-11 23:13:02 +08:00
@okampfer 那还能有把 c 代码变成二进制可执行更复杂吗

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/794664

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX