安装node和spm过程

2019独角兽企业重金招聘Python工程师标准>>>

安装nodejs

官网下载nodejs，我下的是v0.10.33版本，安装到d:\nodejs下。

1.新建目录d:\nodejs，在其中建立node_cache、node_global、node_modules三个目录。
2，将C:\Users\Administrator\AppData\Roaming\npm目录下的文件copy到d:\nodejs\node_global。
3，将C:\Users\Administrator\AppData\Roaming\npm_cache目录下的文件copy到d:\nodejs\node_cache。
4，修改系统变量path=d:\nodejs;d:\js\nodejs\node_global。
5，修改系统变量node_path=d:\nodejs\node_global\node_modules。
6，开启cmd，执行：
npm config set prefix "d:\nodejs\node_global"
npm config set cache "d:\nodejs\node_cache"

windows上运行npm Error: ENOENT, stat 'C:\Users\

windows上运行npm 报Error: ENOENT, stat 'C:\Users\PC111\AppData\Roaming\npm' 错误解决方法

        在windows上装好了node.js 版本为：v0.10.30 。由于不是用的默认安装路径，需要在 报错的路径下 建个名为  npm的文件 ，不要带后缀名哦。报错路径为： C:\Users\“你用户名”\AppData\Roaming\   这个路径下建个npm文件即可正常使用npm 命令了！

优化完毕。


新开启cmd，执行node -v，npm -v，node正常。
查看环境变量：npm config list同4，5设置的一样 


优化成功。


使用npm进行安装时，采用-g指令,会安装到global目录中去。


以上步骤完成后，实际上就是完成了nodejs的绿色化，可随意拷贝到其他电脑中，修改环境变量后就可以用了。


接下来安装express
npm install express -g
可以通过express myapp进行相关测试，在这里就不描述了。


安装sp m

1.npm install spm -g
2.spm help 你会看到所有的命令。我们主要用的命令就是
3.spm build

关于包管理

一旦进入到使用spm的阶段，事情就会一下子复杂起来。毕竟前端开发有自身的特征，模块化的方法从后端进入前端，肯定要有所变化。

首先，spm依赖node.js和npm，而且环境里必须有一个2.6+的python。这一步不算太难，网上大把教程，按步骤就能搞定。

安装好spm之后，就可以将模块的配置、打包、部署都交给它来实现。

比如想要用spm管理一个模块，最好在创建模块的时候，用spm初始化一下，这样会比较方便。步骤如下：

1、创建一个模块专用的目录

2、在目录下使用spm init命令

3、spm会要求你输入一些基本设置信息，然后会自动在目录下创建一些模块的基础文件

整个过程截图如下：

如图所示，输入spm init时，接到的第一个提示是选择初始化模块的类型，一个是arale，一个是alice。好吧，直到这时我才发现，spm的init操作要依赖一个叫源的东西。默认源指向的是官方提供的服务器，服务器上有两个初始化模板可供选择，arale是js模块的模板，alice是css模块的模板，它们都是支付宝的开源项目。

如果运气不好，在运行init的时候可能会遇到这种错误信息：

[WARN] 没有发现源信息  
[ERROR] Caught exception: TypeError: Cannot call method 'filter' of undefined 

不仅仅是init，其他时候也可能出现类似的情况，比如在build的时候出现这种错误：

[ERROR] find gallery/jquery/1.8.3/jquery error!  
[WARN] Cannot find module (gallery/jquery/1.8.3/jquery) from sources!  
[ERROR] find gallery/highcharts/2.3.5/highcharts error!  
[WARN] Cannot find module (gallery/highcharts/2.3.5/highcharts) from sources!  
[ERROR] find gallery/bootstrap/2.3.0/js/bootstrap error!  
[WARN] Cannot find module (gallery/bootstrap/2.3.0/js/bootstrap) from sources!  
[ERROR] find gallery/jquery-tools/cookie/1.0.0/cookie error!  
[WARN] Cannot find module (gallery/jquery-tools/cookie/1.0.0/cookie) from sources! 

所有这些错误，实际原因只有一个：官方提供的源服务不稳定。最好的解决方案是自己搭一个源。建议还是自己搭一个比较安心。具体方法可以到github上找spm的项目，里面有介绍，这里就不多说了。

回到刚才spm init操作，通过spm默认源初始化的模块，目录里面会自动创建若干文件，实际上最核心的文件只有两个，一个是模块根目录下的package.json文件，另一个是src目录下的something.js文件（文件名根据初始化时的输入生成）。

这时如果运行一下spm build，这个命令就会根据package.json里的配置信息，对src/something.js文件进行打包。由于没有修改package.json，所以spm会直接在模块目录下生成一个dist目录，并在里面创建两个打包好的模块文件：something.js（压缩文件） 和 something-debug.js（未压缩文件）。

这就是spm最基本的操作方法，通过修改package.json，可以实现更定制化的打包方式，比如，如果a.js里面引用了b.js和c.js两个模块文件，可以在打包a.js的时候，将b.js和c.js都压缩到a.js里。这时问题就出现了，什么时候采用这种压缩，什么时候不采用？这个问题看似简单，但是非常重要。在实际项目里，模块数量可能会有几十个，而且会有很多的依赖，这时候就要仔细设计一下模块之间的逻辑关系，否则，复杂的模块依赖，会让一切倒退回模块化以前的状态。

模块层级

spm对sea.js提供了很好的支持，但它存在局限性，比如针对单个模块的管理会比较便捷，但是在管理整个项目的众多模块时，使用spm就变得非常繁琐，所以，需要对模块进行分层，区分每一层的目标和使用方法，最简单地方法是分成三个层级：

base层：

这一层一般只有一个模块，该模块负责载入全局共享的一些类库和控件，比如jQuery，ember，es5-safe等。

module层：

这一层是一些细分的模块，比如datepicker、validate、raphael，这些模块都只负责某一个功能，或者只适用于某些特定的场景，它们会被一些页面用到，但没必要让全部页面都引用，所以就尽量分拆。

app层：

这一层的每个模块，都对应到专门的一个页面。它的脚本是为该页面写的，并且根据需要，对module层的模块进行引用。

需要注意的是，在开发过程中，尽量不针对某个模块进行单独打包，比如base层，看起来都是一些通用类库，很稳定，不会经常修改，不如提前打包压缩一个稳定版本。可是，base并不一定像我们想的一样稳定，有时候我们会将一些module层的模块或者方法抽出来，放到base层，这种调整的频率并不低。而在module层和app层，这种调整更是随时都在发生，有些是工程师自己做的调整，有些可能是来自交互、视觉或者产品的调整，对任何模块的提前固化，都可能加重修改时的负担。所以，打包应该在一些关键点上进行，比如提测，比如上线，这时，base层用到的所有全局共享的类库，都压缩到一个base.js文件里，作为一个独立的全局模块使用。app层的各个模块都分别输出，它们用到的module层的模块，都要压缩到自己的文件里，以便减少js载入的文件数量。而module层的模块都已经被压缩到需要出现的地方，所以不再需要压缩输出。

package.json的设置

对模块进行打包处理时，spm会检查模块的package.json，根据里面的配置信息进行打包。问题是，在实际项目里，模块的数量可能会有十几个甚至几十个。如果对每个模块都进行单独处理，会增加非常大的工作量，虽然在package.json里可以标注父级配置，让多个模块共享某些设置，但是这种处理方式有时候可能会适得其反。试想一下，如果我们发现父级配置的一些项目并不通用，应该分拆到适用的模块中，或者众多模块中的配置内容，应该合并到父级配置当中，都不是能够轻松完成的。所以，为了保证package.json的配置工作更为便捷，不如就把整个项目视为一个模块。按照这种想法，目录结构大概可以设为下面这样：

static/
     js/
               base.js
               app1.js
               app2.js
               app3.js
               ...
     js-dev/
          libs/
               jquery.js
               ember.js
               …
          modules/
               m1.js
               m2.js
               ...
          src/
               base.js
               app1.js
               app2.js
               app3.js
               …
          package.json

只保留一个package.json，对全局进行配置，打包的时候，libs目录下的全局脚本都会被压缩到base.js里，modules目录下的模块也不直接输出，它们被哪个app引用，就被压缩到哪个app里。这样设置，开发过程在js-dev目录下进行，需要打包时，通过唯一的配置文件，将base.js和各个app文件输出到js目录下，然后只要在页面加载的地方改一下路径，就可以完成切换。当然这只是一个大概思路，实际应用中还要处理很多问题，比如哪些内容应该放在app层级，哪些应该放在module层级，以及如何结合git或者svn进行代码管理，如何在页面中设置引用，等等等等，都比较麻烦。而且，这一思路也并非通用，不同项目有自己的特征，需要使用不同的方法处理。所以说采用sea.js在带来很多好处的同时，也会增加很多负担，两相权衡，利大就用，弊大则弃。现在的js开发已经变得越来越复杂，如果一项技术不能让你的开发变得更便捷，那最好别用。

转载于:https://my.oschina.net/bigyuan/blog/339280