了解npm的文件结构(npm-folders)和配置文件(npm-mrc)

一、npm的文件结构

  npm的安装:

    本地安装

    • 1. 将安装包放在 ./node_modules 下(运行 npm 命令时所在的目录),如果没有 node_modules 目录,会在当前执行 npm 命令的目录下生成 node_modules 目录。
    • 2. 可以通过 require() 来引入本地安装的包。

    全局安装

    • 1. 将安装包放在 /usr/local 下或者你 node 的安装目录。
    • 2. 可以直接在命令行里使用。

    如果你希望具备两者功能,则需要在两个地方安装它或使用 npm link

  node目录:

    安装目录默认为安装目录。

    在windows中,默认node目录:/ usr / local。

    在Unix系统中,一般安装在{node目录} / bin /目录下而不是{安装目录} / node.exe目录下。

    全局安装目录:

      若设置了node目录,就安装到node目录下,

      若没设置node目录则安装到当前路径目录下

  Node_modules:

    在本地包在node_modules目录下可以按package名称进行加载主要模块,或按package名称/lib/path/to/sub/module目录加载其他模块。

  全局Node_modules:

    在Unix系统中{node目录} / lib / node_modules。

    在Windows中{node目录} / node_modules(即没有lib文件夹。

    包的作用域:node_modules文件夹的子文件夹名与@包有相关作用域。

    例如npm install @myorg/package将包放到/node_modules/@myorg/package目录下能看到所有范围的细节。

    如果需要引入对应的包可以使用require() 引入到本地项目中。

  可执行文件:

    全局:Unix  / bin在目录下引用可执行文件,或在Windows的目录下引用可执行文件。

    本地:在/ node_modules /目录下引用可执行文件。可以通过npm脚本运行。

  手册页:

    全局:在{prefix}/share/man目录下.

    本地或windows不安装npm手册页。

  缓存:

    查看命令:npm-cache(1),参数由缓存配置参数配置

    缓存存放目录:在Posix npm的缓存文件存储在~ /。,或者在Windows~ / npm-cache。

  临时文件:

    临时文件默认存储在指定的文件夹中tmp配置,它的文件格式默认为TMPDIR,tmp,

    临时环境变量:在Unix中为/ tmp。

           在windows中为c: windows TEMP。

    为每个运行程序目录下分配一个临时文件进行程序的记录相关临时信息。如程序的程序的运行、运行成功、运行错误、结束。

  更多信息:

    npm在本地首先会尝试找到当前目录下的根目录寻找foo@1.2.3包。作用cd命令也能到相关目录。

    npm将会从package.json文件或node_modules目录查找包。使用npm命令进行查找包或模块则被视为有效。(这种行为类似于git,使用git-folder进行运行工作目录。)

    如果没有找到包的根目录,则使用当前文件夹。当您运行npm install foo@1.2.3,然后加载到包 缓存,然后打开./node_modules/foo。 然后,任何 foo的依赖性也同样打开./node_modules/foo/node_modules/...

    在/ node_modules / bin目录文件中被依赖。所以必要时通过npm脚本来查找他们。  

  全球安装:如果全局配置被设置为true,那么npm将安装“globally”包。全局安装方式大致相同,但需使用上述"globally"目录。

  生命周期:

    系统模块循环使用模块时会在不同的阶段查找node_modules目录,如果一个包存在node_modules目录的根目录上,则不会出现在当前位置。

    考虑上面的例子,如果在foo -> bar -> barz之外,由于barz依赖于bar,你会想目录结构应是:foo -> bar -> baz -> bar -> baz ...,然而目录结构却是:foo/node_modules/bar/node_modules/barz,因为barz依赖于bar,你的目录结构要是:foo -> bar -> baz -> bar -> baz,当它调用("bar"),它会获得这个副本并代替foo/n ode_modules/bar。

    仅当在多个嵌套node_modules目录中安装完全相同的版本时,才使用此快捷方式。 如果两个“a”包是不同的版本,仍然存在a/ node_modules / b / node_modules / a目录。 然而没有多次重复完全相同的包,将总是防止无限回归。另一个优化可以通过在本地化的“目标”文件夹下安装最高级别的依赖项。另一个优化可以通过安装依赖在最高的层次上,在局部“目标”文件夹中。

    例如:以下这个依赖图:

    

    在这种情况下,我们可能希望这样的文件夹结构:

    

    因为foo直接取决于bar@1.2.3和baz@1.2.3,它们安装在foo的node_modules文件夹中。即使blerg的最新副本是1.3.7,foo对版本1.2.5有特定的依赖。

    所以,安装在[A]。 由于父安装blerg满足bar对blerg@1.x的依赖,它不会在[B]下安装另一个副本。Bar [B]也依赖于baz和asdf,所以这些都安装在bar的node_modules文件夹中。

    因为它取决于baz@2.x,它不能重复使用安装在父节点node_modules文件夹[D]中的baz@1.2.3,并且必须安装自己的副本[C]。

    在bar下面,baz - > quux - > bar依赖创建一个循环。 然而,因为bar已经在quux的祖先[B],它不解压缩另一个bar副本到该文件夹。

    在foo - > baz [D]下,quux的[E]文件夹树是空的,因为它对bar的依赖关系由安装在[B]的父文件夹副本满足。

    可以使用npm ls查看依赖树的结构。

  项目发布:

  在发布npm node_modules文件夹中。如果任何物品没有bundledDependencies数组中,然后他们将不会包含在包tarball。允许维护人员在本地(dev依赖性)使用这个包来安装所有的依赖关系,但只有结集于那些无法找到其他地方的项目。

二、npm的配置文件

  描述:npm从命令行,环境变量和npmrc文件获取其配置设置。npm config命令可用于更新和编辑用户和全局npmrc文件的内容。

  配置文件介绍:

    项目配置文件(/path/to/my/project/.npmrc)
    用户配置文件(〜/ .npmrc)
    全局配置文件($ PREFIX / etc / npmrc)
    npm内置配置文件(/ path / to / npm / npmrc)

    所有npm配置文件都是key = value参数的格式化列表。 环境变量可以使用$ {VARIABLE_NAME}替换。 例如:

    prefix = ${HOME}/.npm-packages

    加载这些文件中的每一个配置选项,并按优先级顺序解析。 例如,userconfig文件中的设置将覆盖globalconfig文件中的设置。

    通过在键名称后面添加“[]”来指定数组值。 例如:

    key[] = "first value"

    key[] = "second value"

    注意:由于本地(每个项目或每个用户).npmrc文件可以包含敏感凭据,它们必须只能由您的用户帐户读取和写入(即必须具有0600的模式),否则将被npm忽略! 

  项目配置文件:

    当在项目中本地工作时,项目根目录中的.npmrc文件(即node_modules和package.json的兄弟节点)将设置特定于此项目的配置值。

    请注意,这仅适用于您运行npm的项目的根。它在您的模块发布时没有任何效果。 例如,您不能发布强制自己在全局或其他位置安装的模块。

    此外,此文件不是在全局模式下读取,例如当运行npm install -g时。

  用户配置文件:$HOME/.npmrc(或userconfig参数,如果设置环境 或在命令行上)

  全局配置文件:$ PREFIX / etc / npmrc(或globalconfig参数,如果设置如上):该文件是key = value参数的ini文件格式化列表。 环境变量可以如上替换。

  内置配置文件:path / to / npm / itself / npmrc 这是一个不可更改的“内置”配置文件,npm在更新中保持一致。 使用npm附带的./configure脚本在此处设置字段。 这主要用于分发维护者以标准和一致的方式重写默认配置。

原文地址:https://www.cnblogs.com/john-sr/p/6063355.html