文章同步发布在了我的 blog http://blog.3qruok.com/posts/12 中
之前在自己的项目中一直使用的 rails 自带的 webpacker 用来处理下面的前端策略: 用 webpacker 处理: tailwindcss + scss + turbo + stimulusjs + action cable 的结构。 随着 rails 7.0 的正式发布, 再参看了 DHH 的对新处理前端的方式的介绍, 我觉得 他提供的第二种访问, 即 jsbundling , cssbundling 的处理方式, 比较适合我现在的项目。
为何我会抛弃 webpacker ?理由主要有如下几点:
那又说到了, 为啥要转化到 jsbundling 和 cssbundling, 而不是 rails 官方最推荐的默认方式: importmap 呢?
那就要分析 importmap 的优缺点了。 这是我总结的 importmap 的优劣。
优势: 因为 importmap 是完全基于浏览器的, 所以启动一个完整的项目, 是可以脱离 nodejs 环境的。 即我们可以完全通过 importmap 对应的 cdn 地址, 也可以实现不同 npm 包, 直接的 import 引用。另外由于不需要本地处理 js, 也就没有裁剪, 压缩啥的在本地运行, 会大大加速了开发的速度。
劣势:
所以我选择了第二种方式 js-bundling 和 css-bundling 来解决我前端问题。
js-bundling 和 css-bundling 是如何解决这些前端的问题的呢? 其实就是 他们只做为 rails 与前端世界的桥梁, 专业的事交给专业的工具来做, bundling 只提供将这些产物于 rails 的传统前端做一个链接。
其实 js-bundling 和 css-bundling 只是一些脚手架脚本, 他们唯一做的事情, 就是将 你用专业的前端工具生成的产物, 连接到 rails 的 sprocket 中去。
我们以 js-bundling 为例, 当你使用 js-bundling 之后, 他会推荐你使用 esbuild 或者 rollup 或者 webpack 来处理你的 js,之后将处理好的产物放在 assets/builds/ 中 之后同时 js-bundling 也会生成一个 assets/config/manifest.js 文件, 在这里指定 所有的 assets/builds 映射到 assets/ 上。 最重要的是, js-bundling 会在你的 assets:precompile 中做一个钩子, 在你 assets:precompile 的时候调用 package.json 中的 对前端的 build 指令, 你可以打开 package.json 看 到, 这里的 dev 实际上就是用 你选择的 或 esbuild, 或 rollup 或 webpack, 将你的前端文件, 最后打包到 assets/builds 文件夹里去。
最后, 就是 rails 4 时代大家比较熟悉的事情。将你生成的前端文件, 算 hash, 生成文件, 丢到 public/assets 下。
css-bundling 和 js-bundling 的效果几乎一样, 唯一的区别是, 他的脚手架代码 换成了 build 时候使用 sass 或者 tailwindcss 或者 postcss 而已。
那么, js-bundling , css-bundling 的优势是什么呢?
那有没有劣势呢?我觉得有以下几点值得注意:
当我确认我能够客服这些劣势后, 我认为 js-bundling 和 css-bundling 给我带来的优势是非常大的, 于是我选择了这种前端模式
最后, 我采取的模式是 js-bundling 配套 esbuild 处理 js , css-bundling 结合 postcss 处理 css。
在这里需要额外说明的是,当我使用了 esbuild 后, 原来默认的 webpack 的读取文件的方式就不可用了。 在我的架构中, 主要影响的是 stimulujs 的引用和 channels 的引用。 原来那种获取当前目录下的所有文件, 以及批量导入当前目录所有文件的语法, 实际是基于 webpack 的, 现在都需要手动将每个文件引用, 抽空我再写下这个改造过程。