我经常从有经验的开发人员节点听说在node_modules检查是很好的做法。 但是,大多数开发人员编写在Mac /达尔文64,但在Linux上部署64位。
如果一个节点发生模块在C写的,我在其上安装OS X,我岂不要重建它在Linux上?
我经常从有经验的开发人员节点听说在node_modules检查是很好的做法。 但是,大多数开发人员编写在Mac /达尔文64,但在Linux上部署64位。
如果一个节点发生模块在C写的,我在其上安装OS X,我岂不要重建它在Linux上?
答案是: 这取决于包
大多数软件包的确需要重新安装,因为node gyp
编译器不通过交叉编译默认情况下-感谢@tkone。
像一些包node-sass
动态下载预编译的二进制的相关平台(以前node-sass
用于包含所有平台的二进制文件,但是这最近改了)。
现在的当前节点萨斯3.4.2不包括在最初下载NPM包二进制文件(如故宫包缓存发现在~/.npm
)。
它所做的是,它的install.js脚本下载特定于平台的二进制文件 ,并将其存储在vendor/{platform}-{arch}-{process.versions.module}.node
。 一旦安装,install.js脚本通常都不会再由NPM调用。
所以,当你在检查node_modules
,它将包含二进制仅供您最初的平台。
对于它的乐趣我搬走下载的二进制文件,这应该是同别人检查你node_modules
在不同的平台。 当再运行,节点萨斯是如此聪明,检测所需的二进制文件不存在。 它正常退出,建议运行npm rebuild node-sass
(当您更改节点版本还暗示,这通常是必要的)。 这将下载的二进制文件当前平台,然后一切都很好。
然而,这完全特定节点萨斯与二进制其他包的行为可能完全不同。
(见Node.js的发行版本的的解释process.versions.modules
决定在二进制下载URL的最后一个数字亦称NODE_MODULES_VERSION,以二进制名称在构建function getBinaryName()
在〜/ .npm /节点SASS / {版本} /package.tgz/lib/extension.js)