V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
weimo383
V2EX  ›  程序员

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

  •  
  •   weimo383 · 73 天前 via Android · 10382 次点击
    这是一个创建于 73 天前的主题,其中的信息可能已经有所发展或是发生改变。
    被 webpack 整晕的一天。想问问后端构建工具是不是很方便🌚🌚
    119 条回复    2021-08-11 23:13:02 +08:00
    1  2  
    mrouyoung
        101
    mrouyoung   72 天前
    最近学习 webpack,单独从零不用任何脚手架的话 配一个 React 项目需要配好多东西,很多配置项虽然官网有描述但是实际因为看不到体现在哪里就很费解,所以很多配置项不知道该不该配。

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

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

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

    ----

    对比一下 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
        107
    ZxBing0066   71 天前
    @pabupa 面对固定场景 那就不要选择 webpack,而去选择封装好的 cra 、vue-cli 这些东西,而这些底层都是 webpack,只是针对 lz 提问解释为什么这么复杂而已
    bnm965321
        108
    bnm965321   71 天前
    @abcbuzhiming npm 作为包管理器来说是先进的,你的逻辑是错误的,不能说作者觉得有瑕疵就不代表它在同时代有先进性。我觉得他比同时代的 pip 好用很多,后来的 cargo 也收到了 npm 的影响
    seakingii
        109
    seakingii   71 天前
    前端构建确实不爽,现在 VUE 的作者搞的 VITE 就是想超越 WEBPACK,可以试试 VITE
    abcbuzhiming
        110
    abcbuzhiming   71 天前
    @bnm965321 作者用词可不是瑕疵,用的是“错误”和“困境”。你觉得你比作者更理解 npm ?

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

    vite + esbuild + ts-morph
    catbestme
        118
    catbestme   71 天前
    @qrobot
    你那说的只是理论骨架,实际的 webpack 配置是互相嵌套,互相引用,关系错综复杂,感觉非常混乱,用起来非常恶心
    newmlp
        119
    newmlp   71 天前
    @okampfer 那还能有把 c 代码变成二进制可执行更复杂吗
    1  2  
    关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4084 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 21ms · UTC 02:56 · PVG 10:56 · LAX 19:56 · JFK 22:56
    ♥ Do have faith in what you're doing.