@ruomu 可以的，我们同时也在招聘NodeJS的职位，我们主要看的是自学能力和态度，当前能力和经验都可以提高的。当然也希望在考虑应聘前，要对Ruby/ Rails和web开发的基础都有个熟悉。请投简历

炮哥帮忙推荐下！

这是一个例子，注意目录结构，外部的calendar.js里的这句话，会引用calendar/目录下index.js文件

@huacnlee 反向查询count时，如果之前没有请求一下Origin Object， 会导致Target Object xxx_by_users method undefined, 例如:

#User Model
action_store :star, :article, counter_cache: true, user_counter_cache: true

#但是在测试里
@article = create(:article)
@article.star_by_users  #method missing error
User #随便读一下user class
@article.star_by_users # => []

觉得CtrlP已经够用了，代码片段一边用ack-grep

真要对比出来，可能要新开篇去说了。只能说下对于小公司来说，webpacker有点给我们带来这些好处: （1）以前前端同学写完后推代码，等运维同学拉代码部署到运行容器，接上数据查看有没出错，出错了还要重来一遍。现在直接本地可以同步效果，在同一个环境下不会再存在一些额外需要去把API服务器调跨域之类的问题。 (2) precompile后的工作和assets pipeline差不多，原来的部署脚本也一步到位了 (3) 像基本我们百分百对外项目静态文件都用到CDN的，用手动分离的方式中间要做很多的整合工作。 (4)和assets pipeline对比的优点就更不用说啦，yarn 对比gem，babel es6 es7 特性对比coffee，webpacker自带处理的各种vue-loader啊，portcss之类的，assets pipeline都会很别扭。

综合地来说，就是对前端用得比较深的，都知道现在webpacker是大一统，前端最前沿的技术都在这里可以体验。assets pipeline和turbolinks是能顶大部分的需求，还是看项目情况使用吧。

这种处理方式也是可行的。实际上我们现在一个在做的项目，已经会有多个分离出来的App入口，还有后台的前端部分也分离出来了,对于我们来说在webpack配置文件里做好入口判断会清晰点。

Rails里的webpack默认配置文件shared.js，是会把packs文件夹下根目录js文件都当作entry打包，会导致不必要的entry重复打包的问题。这里可以手动指定一下自己的entry，这样会大幅减少文件体积和提高打包速度。

example:

module.exports = {
  //手动指定两个入口
  entry: {
    'main': ["./app/javascript/packs/main"],
    'operate/main': ["./app/javascript/packs/operate/main"]
  },
  //下面是原来的配置
  //packPaths.reduce( 
    //(map, entry) => {
      //const localMap = map
      //const namespace = relative(join(paths.source, paths.entry), dirname(entry))
      //localMap[join(namespace, basename(entry, extname(entry)))] = resolve(entry)
      //return localMap
    //}, {}
  //),

  output: {
    filename: '[name].js',
    path: resolve(paths.output, paths.entry),
    publicPath
  },
........
}

更新了开发中遇到的一些小问题

好文，观点都赞同