• #21楼 @darkbaby123 所有语言都可以不在乎依赖对项目产生的影响, 偏偏 JavaScript 不行... 哪天干掉浏览器其实也行, 因为别的用 JavaScript 的地方其实也不在乎大小依赖这件事..

  • #19楼 @luikore 早些年有人投入 compressor 事业, 也不会有 small-focused-module 这种事.. 主要还是那些人在瞎搞事...

  • 我心目中理想的 JavaScript 工程化应该是 Yarn + rollup + small focused modules, 这个估计是办不到了.

    所以, 我现在还是会用 url download + concat + order 的方式来打包自己的类库, 手动 resolve dependencies.

    毕竟在做产品的过程中, 还是比较关注打包后前端的文件引用的大小, 自己控制依赖比打包好后去发现文件为什么这么大成本低多了.

  • 好处就是 yarn.lock 锁定版本, npm 这个问题很严重.

    安装上是有很大进步的, 有一个 repo 的地方.

    总的来说, 我觉得没什么大的变化. 跟 npm 区别并不大. 可以替换 npm 但并不解决本质问题.

    yarn 还是解决不了一些最基本的依赖问题, yarn install --flat 的时候有冲突其实你还是无能为力, 其实需要用户自己去 resolve dependencies, 这个过程就很麻烦了. 而且这个只能靠社区来推动, 因为你也处理不了两个包依赖的 underscore 版本不一致类似这样的问题.

    真的要解决这个问题, 其实应该从本身 npm 的社区的类库入手, 像 small focused modules 这种东西, 在有新的 ES6 tree-shaking 技术支持的情况下, 这里应该像其他语言类库, 类似 Ruby 一样变成相对大的类库. 这样在打包的时候 resolve dependencies 才有意义. 不然装一个 react, 依赖了成百个包. 这成百个包都有可能会升级, 会依赖. 你怎么 resolve dependencies… 基本是不可能的任务.

  • #7楼 @huacnlee 看来大家都在用 Go 做些事情. 我们主要是在 Docker 的基础上做 PaaS, 周边生态都是 Go, 所以要用.

  • #8楼 @lgn21st 重载没啥用, 还是需要一个 src 目录. 对于有强迫症的人来说受不了... 😖😖😖

  • GOPATH 就是最大的遗毒...

    虽然现在也在用 glide, 但是 src pkg bin 目录简直没法用.

    最简单的需求, 保证依赖与自己的源码分开. 用户可以自定义源码路径.

  • 前端架构分享 at 2015年05月30日

    #20楼 @mimosa

    还在杭州, 有时间大家约出来嗨...

  • 前端架构分享 at 2015年05月29日

    #14楼 @rei

    嗯, 这个工具和架构是与 Rails 无关的, 当初写的时候也不是用在 Rails 上面的, 现在我们后端对接的是 Java 平台.

    各取所需吧.

  • 前端架构分享 at 2015年05月29日

    #9楼 @w7938940

    去掉 Asset Pipeline, 在启动 rails 的过程中再启动 linner 就好了, 可以通过一个 rake 命令挂起来.

    在 application.erb 里面直接写最终的 assets 链接就好了, 很简单的.

blog地址:saito.im twitter地址 : twitter.com/SaitoWu github地址 : github.com/SaitoWu

nerazzurri programmer

靠写点程序糊口,期待能在北看台看场米兰德比.