感觉现在的组件管理有点乱了，不知道后续的计划是什么？

[codering]

同一个组件，可以来自github, 也可以是npm，现在看到reademe里说可以通过插件直接使用npm安装的组件。
不知道后续到底以什么为主线？

[2betop]

目前很多产品生态都往 npm 靠，所以我们目前也在尝试 npm, 试水一段时间后，如果 npm 能满足需求，自然用 npm 最好，最直接！

[codering]

直接用npm是能省很多事。
但是它的依赖有点繁杂，当初fis组件仓库建立的一个缘由 不就是看 bower管理的东西太乱吗？

[andycall]

为了组件复用就无法避免出现组件太多零碎的情况，所以就需要一个强大的依赖管理工具和庞大的组件生态圈。npm是现在最强的版本控制工具也是最完善的组件仓库。为了减少大家的开发工作量，支持npm也是大势所趋。

[fancyboynet]

用npm的生态圈，那不考虑私有组件的情况了？
－－－－－
刚看了下，npm有自己的私有模块机制，可是要怎么解决编译时避开node_modules下不相关的非静态的js呢？

[andycall]

啥叫非静态的js。。

[andycall]

对于私有模块， 你可以在package.json 里用
"jquery-mockjax": "git+https://github.com/andycall/jquery-mockjax",
来写内网git仓库的模块

[fancyboynet]

@andycall 就是非在浏览器中跑的js,node_modules下不是还会有很多本地构建相关的模块吗

[andycall]

fis3-hook-node_modules 是参照browserify 来设计的。 引用一段browserify文档的一段话
所做的工作也和browserify保持一致。

compatibility

Many npm modules that don't do IO will just work after being
browserified. Others take more work.

Many node built-in modules have been wrapped to work in the browser, but only
when you explicitly require() or use their functionality.

When you require() any of these modules, you will get a browser-specific shim:

• assert
• buffer
• console
• constants
• crypto
• domain
• events
• http
• https
• os
• path
• punycode
• querystring
• stream
• string_decoder
• timers
• tty
• url
• util
• vm
• zlib

Additionally, if you use any of these variables, they
will be defined
in the bundled output in a browser-appropriate way:

• process
• Buffer
• global - top-level scope object (window)
• __filename - file path of the currently executing file
• __dirname - directory path of the currently executing file

[ystarlongzi]

感觉由于 react、webpack 的兴起，以及 webpack 解决包依赖的思路(可以直接 require 到 npm 包)，再加上 bower 本身也存在一些问题，然后现在大家又都更加倾向于将所有包放在 node_modules 里维护。

然后我的观点是， node_modules 更多的是存放构建工具性质的包，而 bower 或 fis-components 存放的是『页面』开发引用的库或框架。

这样结构目录及『库或框架的引用』或许更加清晰些。