https://github.com/nodesource/distributions

常用​

Debian and Ubuntu based distributions​

# Using Ubuntu
curl -fsSL https://deb.nodesource.com/setup_14.x | sudo -E bash -
sudo apt-get install -y nodejs

# Using Debian, as root
curl -fsSL https://deb.nodesource.com/setup_14.x | bash -
apt-get install -y nodejs

Enterprise Linux based distributions​

Run on RHEL, CentOS, CloudLinux, Amazon Linux or Fedora:

# As root
curl -fsSL https://rpm.nodesource.com/setup_14.x | bash -

# No root privileges
curl -fsSL https://rpm.nodesource.com/setup_14.x | sudo bash -

给公司的文档库写了篇私库开发的 KnowledgeMap，从中摘取一部分。

思考：​

1. 当我们 npm i package 的时候之后，require 或 import 一个包的时时候，是如何寻找到这个包的。
2. 当一个包，在项目中存在多个版本的情况，如何确定引入的是哪个版本。例如项目依赖了 packageA@3.0.0 和 packageB@1.0.0， 而packageB 又依赖了pacakgeA@2.0.0.
3. npm 包是如何提供一个命令的。例如， 当我们安装 npm -g nrm 的时候，为何会有nrm 命令产生。
4. 如何手动发布一个npm 包到公网npm 仓库
5. 包的版本如何定义
6. 什么时候需要发布一个npm 包
7. 什么时间节点需要发布一个 npm 包的新版本，新的版本又该如何定义。

正文​

由于上述问题，涉及到的内容略多，下是推荐和相关的知识点。

1. nodejs的模块解析策略
   1. http://nodejs.cn/api/modules.html
   2. https://www.tslang.cn/docs/handbook/module-resolution.html
2. package.json 字段含义
   1. https://docs.npmjs.com/cli/v6/configuring-npm/package-json
   2. 非官方扩展字段 不在基础node或浏览器环境下支持，但被某些包支持
      • module 指定esm module 的入口文件。 由rollup最早提出(https://github.com/rollup/rollup/wiki/pkg.module), webpack2.x之后版本开始支持
      • types, typings 指定包的d.ts的入口文件，由typescript 支持
      • unpkg 公网npm 包可以使用的的cdn https://github.com/mjackson/unpkg
      • sideEffects Webpack 支持的，用来标记副作用文件，是否可以被TreeShaking
3. esm module 和 cjs module 是什么， 有什么区别
   1. esm https://tc39.es/ecma262/#sec-modules
   2. cjs http://nodejs.cn/api/modules.html
4. 命令的本质就是一个可执行文件，俗称脚本文件。nodejs 产生的js 脚本文件 在使用 #！ /user/bin/env node 指定脚本的运行者。如同shell 脚本需要在文件头指定运行者 #! /bin/bash 一样。
   1. npm 发布相关命令 https://docs.npmjs.com/cli/v7/commands
      • npm login
      • npm public
      • npm deprecate
5. npm 的语义化版本
   1. https://docs.npmjs.com/about-semantic-versioning
   2. https://semver.org
6. 了解包 semantic-release 系列的包 https://github.com/semantic-release/semantic-release
7. 了解 conventional-changelog 系列的包
   1. https://www.conventionalcommits.org/
   2. https://github.com/conventional-changelog

前言 - npm包安全问题​

细数历年npm包安全问题​

• 2021年11月4日, npm包 coa被劫持, 大量react项目被影响. 【部分公司项目，在发布时因其影响而发布失败】
• 2021年10月22日, ua-parser-js被恶意劫持，多个版本植入挖矿脚本
• 2019年7月，有开发者在purescript npm 安装程序中发现一些恶意代码。原来是有攻击者获取了@shinnn（purescript npm 安装程序原始作者）的npm账户，随后在purescript npm安装程序中插入恶意代码。
• 2019年6月，黑客向 npm 发布一个“useful”的包（electron-native-notify），等到它被目标（某应用程序）使用后更新包内容，加入恶意代码。而某应用程序又是 Agama 加密货币钱包的一部分。
• 2018年11月，npm 下载量超过 200 万的 package 被注入了恶意代码，黑客利用该恶意代码访问热门 JavaScript 库，目标是 copay（开源比特币钱包）及其衍生产品的用户，以此窃取用户的数字货币。
• 2018年7月，黑客利用恶意代码破坏ESLint库。该恶意代码被设计用来窃取其他开发人员的npm证书。
• 2018年5月，黑客试图在名为getcookies的流行npm包中隐藏后门。

除了上述恶意的黑客导致的安全问题外，某些npm包，有意或无意的存在各种各样的漏洞或bug。常见的如：DOS, REDOS, Prototype Pollution, XSS漏洞等等。

社区解决方案​

npm audit (npm@>6.x)​

npm 收购nsp后推出的官方检查工具， 之前应该是基于nsp数据库。 目前基于 https://github.com/advisories

npm audit 依赖于npm package-lock.json 或 npm-shrinkwrap.json

常用方法

npm audit # 只扫描，显示有问题的依赖包
npm audit fix #扫描并自动修复和安装符合兼容性要求的包
npm audit fix --package-lock-only #只修改package-lock.json 需要手动安装依赖
npm audit fix --only=prod #扫描并修复
npm audit --audit-level=moderate #设置扫描报告等级

检查报告，会包含有问题的包和版本信息，以及漏洞信息，漏洞的严重程度等等

snyk​

snyk是一家美国的网络安全公司，有自己的安全数据库 同时支持yarn 和 npm

snyk cli 工具是该公司的开源项目https://github.com/snyk/snyk

基础使用方法

# 安装
npm i -g snyk

# 登录, snyk cli 依赖于snyk.io 提供的api
snyk auth

# 扫描
snyk test

snyk 和 npm audit的对比​

这个是snyk公司出的功能对比

观点​

定期或脚本的检查依赖，更新依赖是有必要的，且没有太大成本的。 像前段时间的 ua-parser-js 和 coa事件，都会被上述两种方案所收录。 脚本化的检查，可以在一定程度上避免一些已经被发现的有问题的包，所导致的安全问题。

常用依赖检查命令​

yarn why <pkg> # 查看某npm包依赖关系，项目必须包含yarn.lock
yarn info [pkg] [package.json field] # 查看某包的信息，不传包名，显示当前项目的package.json信息。
yarn info chalk versions # 查看 chalk 目前npm提供的所有版本
yarn info chalk@4.0.0 dependencies # 查看 chalk 4.0.0版本的生产依赖 

npm ls #查看项目依赖树
npm ls [pkg] #查看某包的依赖树
npm ls --depth 1 #限定展示依赖层级

npm outdated #查看项目哪些依赖需要更新

推荐一个检查依赖的第三方包 npm-check-updates​

npm i -g npm-check-updates

ncu # 检查项目所有依赖
ncu -u #检查并更新package.json 需要手动安装依赖
ncu "/.*scope.*/" #检查包含scope关键字的包
ncu -u "/.*scope.*/" #检查包含scope关键字的包,并更新package.json 需要手动安装依赖

NPM: https://www.npmjs.com/package/ynrm Github: https://github.com/mengfei0053/ynrm.git

Fork了狼叔yrm做了一些修改, 可以同时更改yarn 和npm 当前用户的源。

Ynrm 和. Nrm/Yrm​

• 用 typescript 重写了一下
• 将npm从依赖中移除, 通过npm root -g,获取本机的npm
• 使用axios替换request

安装​

$ npm install -g ynrm

Example​

ynrm ls # 查看源

* npm -----  https://registry.npmjs.org/
  cnpm ----  http://r.cnpmjs.org/
  taobao --  https://registry.npm.taobao.org/
  nj ------  https://registry.nodejitsu.com/
  rednpm --  http://registry.mirror.cqupt.edu.cn
  skimdb --  https://skimdb.npmjs.com/registry
  yarn ----  https://registry.yarnpkg.com

# ynrm will set up both npm registy and yarn registry
# switch registry to taobao registry
ynrm use cnpm # 使用源

    YARN Registry has been set to: https://registry.npm.taobao.org/

    NPM Registry has been set to: https://registry.npm.taobao.org/

ynrm add custom_registry https://custom_registry.xx.com # 添加仓库源
ynrm del custom_registry # 删除仓库源
ynrm test # 测试仓库源链接速度

Usage​

Usage: ynrm [options] [command]

  Commands:

    ls                           List all the registries
    use <registry>               Change registry to registry
    add <registry> <url> [home]  Add one custom registry
    del <registry>               Delete one custom registry
    home <registry> [browser]    Open the homepage of registry with optional browser
    test [registry]              Show the response time for one or all registries
    help                         Print this help

  Options:

    -h, --help     output usage information
    -V, --version  output the version number

默认可选仓库源​

• npm
• cnpm
• nodejitsu
• tencent
• taobao
• rednpm
• yarn

关于 shrinkwrap 的更新​

v1.3.16~v2.15.2​

• v1.3.16 (2013-12-11):
  • Stopped re-downloading URL and shrinkwrap dependencies, as demonstrated in #3463 (644c2ff, @spmason). You can use the --force option to force re-download and installation of all dependencies.
• v1.4.1 (2014-02-13):
  • Fix npm shrinkwrap forgetting to shrinkwrap dependencies that were also development dependencies
• v1.4.3 (2014-02-16):
  • Make npm shrinkwrap output dependencies in a sorted order, so that diffs between shrinkwrap files should be saner now. (059b2bf, @Raynos)
• v1.4.7 (2014-04-15):
  • Fix npm crashing when doing npm shrinkwrap in the presence of a package.json with no dependencies. (a9d9fa5, @kislyuk)
• v2.1.8 (2014-11-06):
  • 063d843 npm version now updates version in npm-shrinkwrap.json (@faiq)
  • 3f53cd7 #6559 save local dependencies in npm-shrinkwrap.json (@Torsph)
• v2.1.13 (2014-12-11):
  • cb6ff8d #6879 npm version: Update shrinkwrap post-check. (@othiym23)
• v2.1.17 (2014-12-25):
  • 6b7c5ec #7011 Send auth for tarball fetches for packages in npm-shrinkwrap.json from private registries. (@othiym23)
• v2.7.1 (2015-03-05):
  • 6823807 #7121 npm install --save for Git dependencies saves the URL passed in, instead of the temporary directory used to clone the remote repo. Fixes using Git dependencies when shrinkwrapping. In the process, rewrote the Git dependency caching code. Again. No more single-letter variable names, and a much clearer workflow. (@othiym23)
• v2.7.3 (2015-03-16):
  • 1549106 #7641 Due to 448efd0, running npm shrinkwrap --dev caused production dependencies to no longer be included in npm-shrinkwrap.json. Whoopsie! (@othiym23)
• v2.8.3 (2015-04-15):
  • 387f889 #7961 Ensure that hosted git SSH URLs always have a valid protocol when stored in resolved fields in npm-shrinkwrap.json. (@othiym23)
• v2.9.1 (2015-04-30):
  • b574076 #8079 Make the npm shrinkwrap documentation use code formatting for examples consistently. It would be great to do this for more commands HINT HINT. (@RichardLitt)
• v2.11.0 (2015-05-21):
  • f87cde5 #8292 Fix typo in an example and grammar in the description in the shrinkwrap documentation. (@vshih)
  • d3526ce Improve the formatting in the shrinkwrap documentation. (@othiym23)

v3.0.0~v3.10.10​

• v3.0.0 (2015-06-25):
  • Install: it works different!
    • #6928 (#2931 #2950) npm install when you have an npm-shrinkwrap.json will ensure you have the modules specified in it are installed in exactly the shape specified no matter what you had when you started.
    • #6913 (#1341 #3124 #4956 #6349 #5465) npm install when some of your dependencies are missing sub-dependencies will result in those sub-dependencies being installed. That is, npm install now knows how to fix broken installs, most of the time.
    • #5465 If you directly npm install a module that's already a subdep of something else and your new version is incompatible, it will now install the previous version nested in the things that need it.
    • a2b50cf #5693 When installing a new module, if it's mentioned in your npm-shrinkwrap.json or your package.json use the version specifier from there if you didn't specify one yourself.
  • Shrinkwraps: they are a-changin'!
    • First of all, they should be idempotent now (#5779). No more differences because the first time you install (without npm-shrinkwrap.json) and the second time (with npm-shrinkwrap.json).
    • #6781 Second, if you save your changes to package.json and you have npm-shrinkwrap.json, then it will be updated as well. This applies to all of the commands that update your tree:
      • npm install --save
      • npm update --save
      • npm dedupe --save (#6410)
      • npm uninstall --save
    • #4944 (#5161 #5448) Third, because node_modules folders are now deduped and flat, shrinkwrap has to also be smart enough to handle this.
    • And finally, enjoy this shrinkwrap bug fix:
      • #3675 When shrinkwrapping a dependency that's both a devDependency and the child of a regular dependency, npm now correctly includes the child.
• v3.1.0 (2015-07-02):
• 57c3cea #8695 Remote packages with shrinkwraps made npm cause node + iojs to explode and catch fire. NO MORE. (@iarna)
• v3.3.0 (2015-08-13):
  • As shrinkwraps don't include dev deps by default. This replaces passing in --dev in that scenario.
• v3.3.7 (2015-10-08):
  • 87336c3 #9879 npm@3's shrinkwrap was refusing to shrinkwrap if an optional dependency was missing– patch it to allow this. (@mantoni)
• v3.3.10 (2015-10-22):
  • SHRINKWRAP + DEV DEPS NOW RESPECTED
  • eb28a8c #9647 If a shrinkwrap already has dev deps, don't throw them away when someone later runs npm install --save. (@iarna)
• v3.3.11 (2015-10-29):
  • PARTIAL SHRINKWRAPS, NO LONGER A BAD DAY
  • We're ignoring the version check on things specified in the shrinkwrap so that you can override the version that will be installed. This is because you may want to use a different version than is specified by your dependencies' dependencies' package.json files.
• v3.7.3 (2016-02-11):
  • 42a4727 #11391 Fixed versions of shrinkwrap.json in examples in documentation for npm shrinkwrap, which did not quite match up. (@xcatliu)
• v3.8.9 (2016-04-28)：
  • 60da618 #12347 Fix a bug that could result in shrinkwraps missing the resolved field, which is necessary in producing a fully reproducible build. (@sminnee)
• v3.9.1 (2016-05-12)：
  • b894413 #12372 Changing a nested dependency in an npm-shrinkwrap.json and then running npm install would not get up the updated package. This corrects that. (@misterbyrne)
• v3.9.2 (2016-05-17):
  • This is a quick patch release. The previous release, 3.9.1, introduced a bug where npm would crash given a combination of specific package tree on disk and a shrinkwrap.
  • cde367f #12724 Fix crasher when inflating shrinkwraps with packages on disk that were installed by older npm versions. (@iarna)
• v3.10.0 (2016-06-16):
  • NEW LIFECYCLE SCRIPT: shrinkwrap
  • e8c80f2 #10744 You can now add preshrinkwrap, shrinkwrap and postshrinkwrap to your package.json scripts section. They are run when you run npm shrinkwrap or npm install --save with an npm-shrinkwrap.json present in your module directory.
  • preshrinkwrap and shrinkwrap is run prior to generating the new npm-shrinkwrap.json and postshrinkwrap is run after. (@SimenB)
• v3.10.4 (2016-06-30):
  • SHRINKWRAP IS COMPLICATED BUT IT'S BETTER NOW
  • @iarna did some heroic hacking to refactor a bunch of shrinkwrap-related bits and fixed some resolution and pathing issues that were biting users. The code around that stuff got more readable/maintainable in the process, too!
  • 346bba1 #13214 Resolve local dependencies in npm-shrinkwrap.json relative to the top of the tree. (@iarna)
  • 4a67fdb #13213 If you run npm install modulename it should, if a npm-shrinkwrap.json is present, use the version found there. If not, it'll use the version found in your package.json, and failing that, use latest. This fixes a case where the first check was being bypassed because version resolution was being done prior to loading the shrinkwrap, and so checks to match the shrinkwrap version couldn't succeed. (@iarna)
  • afa2133 #13214 Refactor shrinkwrap specifier lookup into shared function. (@iarna)
  • 2820b56 #13214 Refactor operations in inflate-shrinkwrap.js into separate functions for added clarity. (@iarna)
  • ee5bfb3 Fix Windows path issue in a shrinkwrap test. (@zkat)
• v3.10.6 (2016-07-07):
  • This week we have a bunch of bug fixes for ya! A shrinkwrap regression introduced in 3.10.0, better lifecycle PATH behavior, improvements when working with registries other than registry.npmjs.org and a fix for hopefully the last don't print a progress bar over my interactive thingy bug.
  • SHRINKWRAP AND DEV DEPENDENCIES
  • The rewrite in 3.10.0 triggered a bug where dependencies of devDependencies would be included in your shrinkwrap even if you didn't request devDependencies.
  • 2484529 #13308 Fix bug where deps of devDependencies would be incorrectly included in shrinkwraps. (@iarna)
• v3.10.7 (2016-08-11):
  • BETTER SHRINKWRAP WITH GIT DEPENDENCIES
    • 0f7e319 #12718 Update outdated git dependencies found in shrinkwraps. Previously, if the module version was the same then no update would be completed even if the committish had changed. (@kossnocorp)
• v3.10.8 (2016-09-08):
  • SHRINKWRAP LEVEL UP
  • The most notable part of this release is a series of commits meant to make npm shrinkwrap more consistent. By itself, shrinkwrap seems like a fairly straightforward thing to implement, but things get complicated when it starts interacting with devDependencies, optionalDependencies, and bundledDependencies. These commits address some corner cases related to these.
    • a7eca32 #10073 Record if a dependency is only used as a devDependency and exclude it from the shrinkwrap file. (@bengl)
    • 1eabcd1 #10073 Record if a dependency is optional to shrinkwrap. (@bengl)
    • 03efc89 #13692 We were doing a weird thing where we used a package.json field installable to check to see if we'd checked for platform compatibility, and if not did so. But this was the only place that was ever done so there was no reason to implement it in such an obfuscated manner. Instead it now just directly checks and then records that its done so on the node object with knownInstallable. This is useful to know because modules expanded via shrinkwrap don't go through this– inflateShrinkwrap does not currently have any rollback semantics and so checking this sort of thing there is unhelpful. (@iarna)
    • ff87938 #11735 Running npm install --save-dev will now update shrinkwrap file, but only if there already are devDependencies in it. (@szimek)
    • c00ca3a #13394 Check installability of modules from shrinkwrap, since modules that came into the tree vie shrinkwrap won't already have this information recorded in advance. (@iarna)
• v3.10.9 (2016-10-06):
  • LIFECYCLE FIXES
    • d388f90 #13942 Fix current working directory while running shrinkwrap lifecycle scripts. Previously if you ran a shrinkwrap from another lifecycle script AND node_modules existed (and if you're running npm shrinkwrap it probably should) then npm would run the shrinkwrap lifecycle from the node_modules folder instead of the package folder. (@evocateur) (@iarna)
    • c3b6cdf #13964 Fix bug where the uninstall lifecycles weren't being run when you reinstalled/updated an existing module. (@iarna)
    • 72bb89c #13344 When running lifecycles use TMPDIR if it's writable and fall back to the current working directory if not. Previously we just assumed TMPDIR wouldn't be writable (as we might have been running as nobody and nobody on some systems can't write to TMPDIR). (@aaronjensen)
  • SHRINKWRAP GIT & TAGGED DEPENDENCY FIX
    • 3b5eee0 #13941 Fix git and tagged dependency matching with shrinkwraps. Previously git and tag (ie foo@latest) dependencies installed from a shrinkwrap would always be flagged as invalid. (@iarna)
• v3.10.10 (2016-11-04):
  • See the discussion on #14042 for more context on this release, which is intended to address a serious regression in shrinkwrap behavior in the version of the CLI currently bundled with Node.js 6 LTS "Boron". You should never install this version directly; instead update to npm@4, which has everything in this release and more.
  • REGRESSION FIX
    • 9aebe98 #14117 Fixes a bug where installing a shrinkwrapped package would fail if the platform failed to install an optional dependency included in the shrinkwrap. (@watilde)

v4.0.0~v4.6.1​

• v4.0.0 (2016-10-20):
  • Partial shrinkwraps are no longer supported. npm-shrinkwrap.json is considered a complete installation manifest except for devDependencies.
  • BUGFIXES
    • bc84012 #14117 Fixes a bug where installing a shrinkwrapped package would fail if the platform failed to install an optional dependency included in the shrinkwrap. (@watilde)
  • NO MORE PARTIAL SHRINKWRAPS (BREAKING)
    • That's right. No more partial shrinkwraps. That means that if you have an npm-shrinkwrap.json in your project, npm will no longer install anything that isn't explicitly listed there, unless it's a devDependency. This will open doors to some nice optimizations and make use of npm shrinkwrap just generally smoother by removing some awful corner cases. We will also skip devDependency installation from package.json if you added devDependencies to your shrinkwrap by using npm shrinkwrap --dev.
    • b7dfae8 #14327 Use readShrinkwrap to read top level shrinkwrap. There's no reason for npm to be doing its own bespoke heirloom-grade artisanal thing here. (@iarna)
    • 0ae1f4b 4a54997 f22a1ae 3f61189 #14327 Treat shrinkwrap as canonical. That is, don't try to fill in for partial shrinkwraps. Partial shrinkwraps should produce partial installs. If your shrinkwrap contains NO devDependencies then we'll still try to install them from your package.json instead of assuming you NEVER want devDependencies. (@iarna)
• v4.0.2 (2016-11-03):
  • SMALLER CHANGES
    • 7f41295 #14519 Document that as of npm@4.0.1, npm shrinkwrap now includes devDependencies unless instructed otherwise. (@iarna)
• v4.5.0 (2017-03-24):
  • NO SHRINKWRAP, NO PROBLEM
    • Previously we needed to extract every package's tarball to look for an npm-shrinkwrap.json before we could begin working through what its dependencies were. This was one of the things stopping npm's network accesses from happening more concurrently. The new filtered package metadata provides a new key, _hasShrinkwrap. When that's set to false then we know we don't have to look for one.
  • 4f5060eb3 #15969 Add support for skipping npm-shrinkwrap.json extraction when the registry can affirm that one doesn't exist. (@iarna)

v5.0.0~v5.10.0 (开始引入 package-lock.json)​

• v5.0.0 (2017-05-25):
  • npm will --save by default now. Additionally, package-lock.json will be automatically created unless an npm-shrinkwrap.json exists. (#15666)
  • package locks no longer exclude optionalDependencies that failed to build. This means package-lock.json and npm-shrinkwrap.json should now be cross-platform. (#15900)
  • Shrinkwrap and package-lock no longer warn and exit without saving the lockfile.
  • A new, standardised lockfile feature meant for cross-package-manager compatibility (package-lock.json), and a new format and semantics for shrinkwrap. (#16441)
  • --save is no longer necessary. All installs will be saved by default. You can prevent saving with --no-save. Installing optional and dev deps is unchanged: use -D/--save-dev and -O/--save-optional if you want them saved into those fields instead. Note that since npm@3, npm will automatically update npm-shrinkwrap.json when you save: this will also be true for package-lock.json. (#15666)
  • Indentation is now detected and preserved for package.json, package-lock.json, and npm-shrinkwrap.json. If the package lock is missing, it will default to package.json's current indentation.
• v5.0.4 (2017-06-13):
  • 800cb2b4e #17076 Use legacy from field to improve upgrade experience from legacy shrinkwraps and installs. (@zkat)
• v5.1.0 (2017-07-05):
  • 4f45ba222 a48958598 901bef0e1 #17508 Add a new requires field to package-lock.json with information about the logical dependency tree. This includes references to the specific version each package is intended to see, and can be used for many things, such as converting package-lock.json to other lockfile formats, various optimizations, and verifying correctness of a package tree. (@iarna)
  • 3b4681b53 #17508 Stop calling addBundle on locked deps, speeding up the package-lock.json-based fast path. (@iarna)
  • It introduces a new package-lock.json field, called requires, which tracks which modules a given module requires.
  • It fixes #16866, allowing the package.json to trump the package-lock.json.
  • 47e8fc8eb #17508 Make npm ls take package locks (and shrinkwraps) into account. This means npm ls can now be used to see which dependencies are missing, so long as a package lock has been previously generated with it in. (@iarna)
  • 99ef3b52c #17505 Stop trying to commit updated npm-shrinkwrap.json and package-lock.json if they're .gitignored. (@zkat)
• v5.2.0 (2017-07-05): （开始加入npx）
  • c0a289b1b #17606 Make sure that when write package.json and package-lock.json we always use unix path separators. (@Standard8)
• v5.4.0 (2017-08-22):
  • b6d5549d2 #17844 Make package-lock.json sorting locale-agnostic. Previously, sorting would vary by locale, due to using localeCompare for key sorting. This'll give you a little package-lock.json churn as it reshuffles things, sorry! (@LotharSee)
• v5.6.0 (2017-11-27):
  • bc263c3fd #19054 Fully cross-platform package-lock.json. Installing a failing optional dependency on one platform no longer removes it from the dependency tree, meaning that package-lock.json should now be generated consistently across platforms! 🎉 (@iarna)
  • f94fcbc50 #19160 Add --package-lock-only config option. This makes it so you can generate a target package-lock.json without performing a full install of node_modules. (@alopezsanchez)
  • a93e0a51d #18846 Correctly save transitive dependencies when using npm update in package-lock.json. (@iarna)
• v5.7.0 (2018-02-20):
  • Allow npm install to fix package-lock.json and npm-shrinkwrap.json files that have merge conflicts in them without your having to edit them. It works in conjunction with npm-merge-driver to entirely eliminate package-lock merge conflicts.
  • e27674c22 Automatically resolve merge conflicts in lock-files. (@zkat)
• v5.8.0 (2018-03-08):
  • 2f513fe1c #19904 Make a best-attempt at preserving line ending style when saving package.json/package-lock.json/npm-shrinkwrap.json. This goes hand-in-hand with a previous patch to preserve detected indentation style. (@tuananh)
  • d3cfd41a2 pacote@7.6.1 (@zkat)
    • Enable file:-based resolved URIs in package-lock.json.
    • Retry git-based operations on certain types of failure.
  • fc8761daf #19629 Give more detailed, contextual information when npm fails to parse package-lock.json and npm-shrinkwrap.json, instead of saying JSON parse error and leaving you out in the cold. (@JoshuaKGoldberg)
• v5.9.0 (2018-03-23):
  • If you resolve a package-lock.json merge conflict with npm install we now suggest you setup a merge driver to handle these automatically for you. If you're reading this and you'd like to set it up now, run:
  • npx npm-merge-driver install -g
  • 5ebe99719 #20071 suggest installing the merge driver (@zkat)
• v5.10.0-next.0 (2018-04-12):
  • f18be9b39 #20154 Let version succeed when package-lock.json is gitignored. (@nwoltman)
  • 8e21b19a8 #20140 Note in documentation that package-lock.json version gets touched by npm version. (@srl295)
• v5.10.0-next.1 (2018-05-07):
  • SHRONKWRAPS AND LACKFILES
  • If a published modules had legacy npm-shrinkwrap.json we were saving ordinary registry dependencies (name@version) to your package-lock.json as https:// URLs instead of versions.
    • 36f998411 When saving the lock-file compute how the dependency is being required instead of using _resolved in the package.json. This fixes the bug that was converting registry dependencies into https:// dependencies. (@iarna)
    • 113e1a3af When encountering a https:// URL in our lockfiles that point at our default registry, extract the version and use them as registry dependencies. This lets us heal package-lock.json files produced by 6.0.0 (@iarna)
  • MORE package-lock.json FORMAT CHANGES?!
    • 074502916 #20384 Add from field back into package-lock for git dependencies. This will give npm the information it needs to figure out whether git deps are valid, specially when running with legacy install metadata or in --package-lock-only mode when there's no node_modules. This should help remove a significant amount of git-related churn on the lock-file. (@zkat)
  • 1b535cb9d #20358 npm install-test (aka npm it) will no longer generate package-lock.json when running with --no-package-lock or package-lock=false. (@raymondfeng)
  • 268f7ac50 5f84ebdb6 c12e61431 #20390 Fix a scenario where a git dependency had a comittish associated with it that was not a complete commitid. npm would never consider that entry in the package.json as matching the entry in the package-lock.json and this resulted in inappropriate pruning or reinstallation of git dependencies. This has been addressed in two ways, first, the addition of the from field as described in #20384 means we can exactly match the package.json. Second, when that's missing (when working with older package-lock.json files), we assume that the match is ok. (If it's not, we'll fix it up when a real installation is done.) (@iarna)

v6.0.0-0~v6.14.15​

初始​

锁版本的起始 npm v1.1.2 版本， 2012年2月25号 https://github.com/npm/cli/commit/d54ce3154dfe5283fcfeffc13d4e003bbade6370#diff-160056e00187b4f9fa30cb1ccf52d15febbae3f425abb1cf72a5e56b388d2a67 这个commit 开始 添加了 npm shrinkwrap v1.1.2 npm-shrinkwrap 解释文档；

By default, "npm install" recursively installs the target's dependencies (as specified in package.json), choosing the latest available version that satisfies the dependency's semver pattern.

When "npm install" installs a package with a npm-shrinkwrap.json file in the package root, the shrinkwrap file (rather than package.json files) completely drives the installation of that package and all of its dependencies (recursively). 

使用方法

1. npm i 递归安装package.json 中记载的依赖，依赖版本选择符合 semver 版本的最新版。
2. 通过 npm shrinkwrap 生成 npm-shrinkwrap.json 文件来保存当前依赖的版本信息
3. 当 npm-shrinkwrap.json 文件存在时,按照此文件中记载的依赖版本，进行安装

当 Node.js 进程收到信号时，则将触发信号事件。 有关标准 POSIX 信号名称（例如 'SIGINT'、'SIGHUP' 等）的列表，请参阅 signal(7)。

信号在 Worker 线程上不可用。

• 'SIGINT' 所有平台都支持来自终端的 'SIGINT'，通常可以使用 Ctrl+C 生成（但是这是可配置的）。 当启用终端原始模式并使用 Ctrl+C 时不会生成它。

• 'SIGKILL' 不能安装监听器，它会无条件地终止所有平台上的 Node.js。

• 发送 SIGINT、SIGTERM、和 SIGKILL 会导致目标进程无条件的终止，之后子进程会报告进程被信号终止。

• 'SIGUSR1' 由 Node.js 预留以启动调试器。 可以安装监听器，但这样做可能会干扰调试器。

• 'SIGTERM' 和 'SIGINT' 在非 Windows 平台上具有默认的句柄，其在使用代码 128 + signal number 退出之前重置终端模式。 如果这些信号之一安装了监听器，则其默认行为将被删除（Node.js 将不再退出）。

• 'SIGPIPE' 默认情况下忽略。 它可以安装监听器。

• 'SIGHUP' 在 Windows 上是在关闭控制台窗口时生成，在其他平台上是在各种类似条件下生成。 参见 signal(7)。 它可以安装监听器，但是 Node.js 将在大约 10 秒后被 Windows 无条件地终止。 在非 Windows 平台上，SIGHUP 的默认行为是终止 Node.js，但一旦安装了监听器，则其默认行为将被删除。

• 'SIGTERM' Windows 上不支持，可以监听。

• 'SIGBREAK' 在 Windows 上，当按下 Ctrl+Break 时会发送。 在非 Windows 平台上，它可以被监听，但无法发送或生成它。

• 'SIGWINCH' 当调整控制台大小时会发送。 在 Windows 上，这只会发生在当光标移动时写入控制台，或者当在原始模式下使用可读的终端时。

• 'SIGSTOP' 不能安装监听器。

• 'SIGBUS'、'SIGFPE'、'SIGSEGV' 和 'SIGILL'，当没有使用 kill(2) 人为引发时，本质上会使进程处于调用 JS 监听器不安全的状态。 这样做可能会导致进程停止响应。

• 0 可以发送来测试进程是否存在，如果进程存在则没影响，如果进程不存在则抛出错误。 Windows 不支持信号，因此没有等价的使用信号来终止，但 Node.js 提供了一些对 process.kill() 和 subprocess.kill() 的模拟：

• 发送信号 0 可以作为独立于平台的方式来测试进程是否存在。

• 前端自动化测试
  • 前言
  • 测试框架

在公司开始尝试推行编写前端测试用例

前言​

测试种类繁多，但测试的最终目的，无外乎保从各个环节障程序的健壮，稳定。

// 目录:/assets/share03/软件测试.xmind

• 单元测试

  • 前端测试粒度常见以函数，类，组件，模块等为单位，编写测试代码。(当前项目环境中欠缺)

• 集成测试

  • 多模块联合起来是否符合功能预期的测试。(目前主要依赖测试人员的手工测试,脚本测试)

• 系统测试

  • 通常用黑盒的方式进行，包括健壮性测试，性能测试，功能测试，用户界面测试，压力测试等。在不断的需求变更后，进行回归测试，保证程序的可用性。（类比我们 stage 上的回归测试）

• 验收测试

  • 内测(alpha， 可以类比我们的 A 环境测试)，公测(beta，可以类比我们的 B 环境测试)。

  // 目录: /assets/share01/React 前端测试.xmind

测试框架​

• jest
  • github https://github.com/facebook/jest
  • 英文 https://jestjs.io/
  • 中文 https://www.jestjs.cn/
• cypress
  • github https://github.com/cypress-io/cypress
  • 英文 https://www.cypress.io/