问： "总感觉深度融合前端，在一定程度上阻碍了框架的更流行？!!"

答：一定范围内，是的，rails 想做的事情太多，但是大多数人的耐心是有限的，或者职责是有限的，只不过对于创业者来说，rails 提供了一揽子解决方案。

问： “抛出问题：webpack 是前端打包工具，而 npm 安装的包又是运行在 node 上的 js 包。那么：npm 安装的包是不是经过 webpack 打包而来的？比如 bootstrap、JQuery、vue 等。”

答：webpack 是一种打包方式，npm 包不依赖 webpack，webpack 最本质的目的是为了处理不同 js 文件的互相引用问题。webpack 还有很多前辈或者同辈也在解决这个问题，例如 grunt. gulp 等。至于裁剪，压缩，顺带解 css 啥的，是他的附带业务，不是主业。

其他的内容 恕我语文不太好，没明白你的意思。

Rails 的这一套前后端一把梭曾经辉煌过，不过当下前端已经完全不需要 Rails 了，至于后端，Java 恐怕永远是老大。即便让我写一套全栈的，那也是选择 Node.js 写后端

Rails7 提供了可选前端方案，官方推出的 Hotwire 生态还是白板，轮子基本需要自己撸。所以目前还是 Rails6 时代的 Webpacker 是比较成熟好用。webpacker 和 rails 结合一般是 2 种方法：

1 使用 React/vue/Angular 接管前端路由。rails 只提供 API。

好处：几乎可以利用全部前端生态。

弊端：需要管理前后端 2 套路由，增加心智维护成本和开发量，很多简单的页面本来 render 一下的事，就需要分别写一个前端页面 +1 个 API。而且两套路由，在做权限管理的时候就会非常抓狂。

2 使用 Rails 的路由 + 部分 React/Vue 的页面渲染+Turbolinks/Turbo(可选)

好处：

• 灵活自由
• 一套 restful 路由非常整洁。
• 简单的展示页面/列表不用去写前端 js 部分。

弊端：

• 需要自己处理 Turbolinks/Turbo 的一些坑，当然可以选择禁用。
• 前端生态圈很多轮子不能开箱即用了，需要自己配置折腾一下。甚至有些根本不能用。
• 需要维护 2 套 view 文件，其中 rails 那套可能就一行代码，但是必须写，很烦人。

回答问题

1) 如果使用 yarn add xxxx 其他的 js 库，是不是意味着 import xxxx 就可以找到 ?

是的

2) 如果自己编写的 yyyy.js 放在 app/javascript/packs, 应该写 import yyyy 嘛？

写相对路径

import xxx from './yyyy'

3) bootstrap 依赖 jquery，导入了 bootstrap 是不是不用在单独导入 jquery？

把 jquery 注册到全局就行了，你参考下这个 config/webpack/environment.js ，VUE+jquery 的

const { environment } = require('@rails/webpacker')
const { VueLoaderPlugin } = require('vue-loader')
const vue = require('./loaders/vue')
const webpack = require('webpack')

environment.plugins.append('Provide',
    new webpack.ProvidePlugin({
        $: 'jquery',
        jQuery: 'jquery',
        Popper: ['popper.js', 'default'] 
    })
)
environment.plugins.prepend('VueLoaderPlugin', new VueLoaderPlugin())
environment.loaders.prepend('vue', vue)
module.exports = environment

4) 这个目录 app/javascript/channels 是做什么用的呢 ?

action_cable组件的默认 js

可以用 rails g channel 生成一个看看里面有什么，主要用于实时通讯，比如聊天室。服务端依赖 redis。

1) 如果使用 yarn add zzzz 其他的 css 库，是不是代表着 @import "path_zzzz" 必须对应到相应的 css 文件？

貌似是的

2) 这个目录 app/assets/stylesheets 默认情况下会创建针对控制器 Controller 的 css 文件，哪里制定它的呢 ?

其实并不需要定制，全部写到 javascript/stylesheets/application.scss 里就行了，因为 require 进来的文件似乎有加载顺序的问题。 如果你用的 vue 或者 react，那你的样式最好遵循前端框架约定。

官网指南看上去还没整明白，望大神指点迷津，有没有 6 版的中文手册之类的...

目前是没有的中文官网指南还是 Rails5 的，不过足够用了。

Rails 是个 MVC 框架，目前 V 还是用前端生态里的实践方案会比较好，Rails 提供的默认前端解决方案并不是很现代，过于强调复用，会导致 view 碎片化。而前端的 C 层解决方案又是堆 shi 山的副产物，而且并不能让后端省去 C 层开发，而导致前后端分裂。所以 Rails 官网指南重点学习 M 和 C 就行了。其他的完全不看都可以，像 mailer action_cable 这些并不是一个 Web Application 必须的。

M 层和 C 层 Rails5 到 Rails7 几乎没有什么变化。而且 Rails 精髓也就在 M 和 C。

非常感谢大神回复！列举了 ruby 下 gem、python 下 pip、node 下 npm，是想证明 npm 安装的包和 webpack 没有一毛钱关系。而 Rails6 引入 webpack 打包静态资源，却要用 npm 方式去安装第三方依赖包，主要是想搞明白它们的关系！至于剩下的问题无非是：如何使用问题？在 webpack 下如何引入已有的前端库，如何引入自实现的文件？研究原理不必要，至少会用嘛。还是很感谢

终究还是上晚了车！基于 rails 这一套有没有可能出现新的框架，这种元编程能力真是又爱又恨啊

满分大神，多谢指教，我去折腾一下

把 npm 和 yarn 安装依赖的行为理解成下载 围绕 JavaScript 的文件到本地会不会更容易理解一些呢？

举个简单的例子，当我们执行

npm i -g @vue/cli

下载的是一个脚手架工具；

执行

npm i bootstrap

下载的是一套 UI 样式库；

更多的时候，我们下载下来的东西可能千奇百怪，可能是 JavaScript 文件，可能是 css 文件，甚至还可能有 cpp 文件（参考 node-sass)……

所以其实打不打包和 npm/yarn 并没啥关系，它取决于作者出于什么样的考虑来实现这个包，如果它只是使用在 NodeJS 环境，打不打包并不会影响正常使用；但如果在浏览器端就可能需要考虑各种适配情况，例如新的 ECMAScript 语法等，通过构建工具优雅降级并压缩非常重要；又例如命令行工具，或许需要考虑的只是各操作系统之间的兼容问题，因此也就没有一定要打包的必要了。

嗯嗯，正对点上了！这样理解顺畅许多！npm/yarn 提供的是包下载能力！至于下载的包有没有经过 webpack 打包处理，那是作者另一个维度考虑了

是的，npm 包确实可以通过 Webpack 进行打包。Webpack fnf 是一种流行的 JavaScript 模块捆绑器，它可以获取各种模块（包括通过 npm 安装的模块），并将它们捆绑在一起以在 Web 应用程序中使用。