Cortex - 让前端开发轻便而有趣

[supersheep]

在生产环境平稳使用了18周126天之后，今天，我们决定把我们的前端包管理工具 —— Cortex 介绍给大家，使更多的前端工程师们从此可以不再烦恼前端组件的版本升级和依赖管理，专心享受创造与分享的乐趣，携手建立一个更好的前端生态。

这一次，我们带来了

* 轻巧而强大的命令行工具

通过 `npm install cortex -g` 进行安装之后，你就可以像开发node模块一样，开发浏览器组件与网站。
我们在 http://ctx.io/get-started 准备了一个简单的示例来带你体验一下cortex的开发流程。

* 方便的搜索服务与social coding站点 http://ctx.io

在这里，你可以轻松找到你想要组件，获得文档，订阅热门贡献者的最新动态。

* 一本不断完善中的git-book小书

帮助你快速了解如何使用cortex来开发、测试、发布组件与网站。http://book.ctx.io


如果你对cortex的代码有兴趣，欢迎来 https://github.com/cortexjs/cortex 转转，使用中有任何问题也欢迎提issue帮助我们一起改进 :)

[villadora]

demo项目: http://cortexjs.github.io/todos.backbonejs/, http://cortexjs.github.io/autocomplete/

欢迎查看demo, 和bootstrap, jquery, backbone这些框架都轻松集成哦

[liaa]

很酷,下次有应用场景时会试一试

[airyland]

重造轮子？看起来不错，但是确定转到spm后就不想折腾其他的了。。

[chemzqm]

当年TJ说 component 要实现自己的 registry，结果是不得已用了很变态的方式实现了 Semantic Version。

[villadora]

@chemzqm component用github做registry name/repo最后就弄的很复杂，而且在公司里面的生产环境就没法用了，不能直接用github也没法自己搭registry

[pepsin]

哈哈，支持一下

[AlanZhang]

这个类似bower吧。

[chemzqm]

@villadora 我到是觉得 name/repo 挺好的，经常是在用别人模块然后发现需要稍微改点才能更好满足需求，因为break api等原因让人家接受PR不太可性，所以干脆直接fork然后改成自己名很方便。
component 1.0支持bitbucket，也可以比较容易的实现自己的registry，我的实现是第一次从 github把代码拉下来，以后除了 master 的代码都直接从本地读取，只是现在版本管理都交给tag，效率很低，也不容易使用

[iwege]

cortex 能用来配合requirejs或者sea.js来用么？还是说只支持点评自己的模块系统？

[kaelzhang]

@iwege 感谢关注~

其实，无论是 browserify 还是 component，都会默认自带模块系统，因为 requirejs 还是 seajs 做的事情很有限，比如对 [semver ranges](https://github.com/mojombo/semver/issues/113) 的支持，对 [file module](http://nodejs.org/api/modules.html#modules_file_modules) 和 dir 的支持，对 __dirname，__filename 的支持，对 require.resolve 的支持。

当有了包管理器之后，模块加载器其实是不需要存在的，而且用户也不需要写 `define`, `define.amd`. 而且现在生态系统并不好，每个开源项目里面都要去写一大堆 AMD, UMD, *MD，它们基本上是我们平时开发过程中不需要去操心的，事实上，我们只需要跟 nodejs 一样写代码就好了。这也是为什么这些 *MD 一直都只是 proposal。
我们永远希望让开发者写更少的东西。

只有 [Module/1.0](http://wiki.commonjs.org/wiki/Modules/1.0) 是必要的

[kaelzhang]

@pepsin 嘿嘿，谢谢

[tinymao]

待过10天左右点评，对 cortext 印象深刻，因为英语不好老是多打一个 t
记得当时是这样， node 起一个服务托管 css/js 。
然后 files:///xx.html 预览，好像没办法直接自动刷新，我做 APP 的，这个只是兼职，所以可能说错了。

[kaelzhang]

@chemzqm 阁下是少有的经常会用包管理的人哪，握个爪。最近正准备写个文章谈谈这个问题。不过从生态环境来看，它会潜在地让用户去制造更多的fork，并且去依赖这些 fork，这个长久来看会有问题的。嘛，而且tj一年前就已经基本上把项目给樱桃哥一个人来维护了，这个才是硬伤 D:

[kaelzhang]

@tinymao 唔，难道是打开方式不对，哪天再来趟点评把，如果是妹子的话手把手教

[kaelzhang]

@AlanZhang 其实 bower 在某种程度上只是一个脚本管理器，把脚本下载到本地，然后让开发者自己搞定后面的事情。另外 bower 并没有用 commonjs，这样一个直接的问题就是，模块间都是用全局变量来交互，这样很糟糕，也因此无法多版本共存。

[JoyNeop]

名字不合适。。。已经被公众默认是 ARM 的商标了。。。

[iwege]

@kaelzhang 我觉得我不关系什么协议的，我只关心运行原理。

从给出的demo来看，你的解决方案按照我比较熟悉的描述就是requirejs的CMD风格， 但是略有不同的是你将__dirname和__filename作为一个参数传递进去。这个倒是不是关键点，不过这种方式却可以简单的解决混淆的问题。这样来看 cortex 只是起了一个server然后将代码包装了一下。把cortex 比作一个简单的express都可以，所以cortex要换成requirejs也相对简单，真正的关键还是在neuron的那套上面的。

按照我的理解，neuron是模块加载，neuron-builder 是模块打包的工具。

不过这里也牵扯出几个问题：
1. 单一模块依赖的第三方模块如何与其他的模块共享，如果采用node 的方式是每个人自带自己的依赖就违反了web领域的优化，唯一命名貌似是唯一的解决方案，但是感觉好麻烦。
2. 非JS层面的依赖无法解决，component 想要解决这个问题，不知道现在解决了没有。
3. 基于前两个问题，怎么解决当前前端共享和打包的问题。


另外neuron-builder 没有针对大小写敏感来设计么？

例如：你的文件名是： c.js，但是在testcase代码里面是：var c = require("./C"); 按照这样的处理结果，如果大小写敏感，应该会直接出错，除非你测试环境都是在windows或者mac非大小写敏感的server上。非大小写敏感的server，虽然会传递script的内容过来，但在requirejs里面，c和C是两个独立的模块（尽管code是一样的）。

[iwege]

另外这个东西还有硬伤：不支持代理。在有代理的公司里面基本上属于不可用状态。

[villadora]

@iwege 关于模块依赖，cortex的方案可以参考博客http://cnblog.ctx.io/post/91333512673/cortex.

非js的依赖其实依赖管理和js的一样已经解决，但非js层面的依赖问题主要在于页面如何按需载入以及如何避免冲突,css里面的资源又如何处理, 这方面实际上大家都还在探索，没有一个满足所有需求的方案。cortex目前也是在管理还依赖的情况下，提供了周边的工具来实现css在html页面的注入。

关于第三点, 不知道共享是指哪个方面，打包现在开发好的cortex项目，本地一个静态服务就可以跑起来，发布打包也就是把cortex install/build之后的项目文件打包好就是一个独立的站点了,比如现在的几个examples都是这么做的。

关于大小写，之前也碰到过，确实需要处理，至于是要像requirejs里面一样是两个独立的，还是统一成小写，这个还希望大家参与讨论, 可以到https://github.com/cortexjs/neuron-builder/issues新建issue.

因为如果是有文件名大小写的不同内容也不同的文件，在windows和mac里面本身这个模块里面的文件就会被自身覆盖, 从而导致出问题。

代理的问题现在还不支持，已经提到issue: https://github.com/cortexjs/neuropil/issues/52

有想法和建议，欢迎提issue～

[iwege]

@villadora 第三点和第一点是有联系的，但是应该不适合web领域。现在所知的模块体系都是源码级别的共享。假设
d
|- a
| |-b
|
|- c
|-b

在源码级别是可以解决的b的依赖重复问题，但是一旦a build成为一个模块，c也同样，那么d在获取ac的时候就依赖了两份b的代码。当然这种主要是针对node-webkit / atom-shell 两个场景下的模块分享问题，而且也算是一个伪命题，因为JS是天然的开源属性...

至于非js依赖，也包含了模板，css，image等，当然都同样不属于web领域...

大小写的问题，最好是两个独立模块，毕竟linux上的server多一点，这种应该只能约束开发规范。只是在windows和非大小写敏感的mac上比较难易调试罢了。

[villadora]

@iwege 所以web领域都没有做套嵌树的模块管理。和node一样的模块管理方式更适合于文件系统，比如node, node-webkit也是这样，不用考虑overhead。像插件更是需要进行模块独立，即使有overhead也是在能不用共享的情况就不使用共享，而自己打包。这个是符合谁使用谁负责的原则的。外层不应该关系内层的实现。

web上的模块管理，cortex都是采用扁平化的，cortex的build的模块也不会包含依赖的重复代码，只会包含自己本身的代码。

d
| - a
| - b
| - c

a依赖于b这个信息都是模块自己申明而不是靠将b整体打包到a中实现, 只要版本兼容，d只会获取a,b,c各一份, 像之前说到的重复就不存在。但这种方式在其他的包管理下会存在冲突的可能，因为b只有一个。

虽然js是开源的，但是每次使用模块都需要用户去自己处理，选择代码甚至修改源码，比如我写d我需要去处理b里面的代码是很奇怪的,就像开发atom的packages的时候如果还要关心别的packages用了哪些依赖一样。

[iwege]

@villadora 嗯，你的解决方案是对的。