Current Layout​

当前约 17 篇 .md 文章（以仓库实际文件为准）。

Tags​

Frontmatter tags 只用英文小写 slug。Docusaurus 3 用 lodash kebabCase 生成标签页路径，所以标签字符串必须已经是目标 slug：AI 会落到 /blog/tags/ai，但 TypeScript 会落到 /blog/tags/type-script，和 typescript 拆成两页。

每篇一个主标签，与所在目录对齐；只有文章确实跨主题时再加次标签，最多 2 个。次标签也必须来自下表。不要再使用 npm、yarn、ts、hooks、Powershell、Test、Jest 等会拆页或与主标签重复的写法。文章 slug 保持不变，只改 tags。

导航「分类」下拉列出上表里已有文章的标签页。「AI」同时保留为顶栏第一项，仍指向 /blog/tags/ai。

Conventions​

• 新文章放在对应主题子目录，文件名可用中文；Docusaurus 会生成 slug。tags 按上一节填写，不要新开同义标签。
• 工具使用指南放在 docs/guides/（站点分类「技术文档」），不要放进 blog/。
• 建议在长文合适位置添加 <!-- truncate -->，否则 pnpm build 会警告 onUntruncatedBlogPosts（不阻断构建）。
• 文内锚点需与标题生成的 id 一致，否则可能出现 onBrokenAnchors 警告。
• 不要在此目录放非 Markdown 构建依赖或密钥。

Local Notes​

常用​

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 -

思考：​

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包安全问题​

• 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 需要手动安装依赖

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

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 文件存在时,按照此文件中记载的依赖版本，进行安装

信号在 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/

React 16.8 加入的特性。 React hooks 允许开发者，在函数组件中，使用 state,和类似生命周期的功能。

基础 hooks​

useState​

概述：用来声明状态，和改变该状态的函数。

参数：状态初始值，或者一个返回初始值的函数。只会在组件出初次渲染时执行。

用法：

const [state, setState] = useState(initialState); // 参考Es6 数组的结构赋值

const [state, setState] = useState(() => {
   const initialState = someExpensiveComputation(props);
   return initialState;
});

eg：

function Counter({initialCount}) {
  const [count, setCount] = useState(initialCount);
  return (
    <>
      Count: {count}
      <button onClick={() => setCount(0)}>Reset</button>
      <button onClick={() => setCount(prevCount => prevCount + 1)}>+</button>
      <button onClick={() => setCount(prevCount => prevCount - 1)}>-</button>
    </>
  );
}

useEffect​

概述：处理具有副作用的行为，例如（订阅，计时器，日志记录等。），并在函数组件渲染结束后运行。

参数：

1. 第一个参数，接收一个可能具有副作用（订阅，计时器，日志记录等。）的函数。该函数的返回值，可能是一个清理函数。
2. 第二个参数（可选），含有执行依赖的数组。当该参数为空数组时，该 effects 只在初次渲染后执行。

用法：

useEffect(
  () => {
    const subscription = props.source.subscribe();
    return () => { // 组件被移除前执行清理函数
      subscription.unsubscribe();
    };
  },
  [props.source], // 依赖改变，订阅函数才会执行
);
useEffect(
  () => {
    const subscription = props.source.subscribe();
    return () => { // 组件被移除前执行清理函数
      subscription.unsubscribe();
    };
  },
  [], // 初次渲染 执行
);

useContext​

const MyContext = React.createContext(defaultValue);
const value = useContext(MyContext);

其他 hooks​

useReducer​

概述：在状态较复杂时使用.我的理解是，和 redux 类似的概念。因为工作一直在 使用 redux。所以这个概念，暂时不做深入了解。以后有机会用到的话，再深入学习。

useCallback​

概述：类似 useMemo，返回一个 callback 函数，

const memoizedCallback = useCallback(
  () => {
    doSomething(a, b);
  },
  [a, b],
);

• 测试中，遇到问题：依赖值没变，但会重新进行计算。
• 有点没搞懂，这个 hook 的使用场景

useMemo​

概述：返回一个计算值，只在依赖发生变化时计算。

const memoizedValue = useMemo(() => computeExpensiveValue(a, b), [a, b]);

useRef​

概述：useRef 返回一个可变的 ref 对象。初始化时，初始化参数将被赋值给该对象的 current 属性。这个 ref 对象，存在在整个组件的生命周期内

最常用的用法，是用 ref 对象存储一个 dom 对象。eg:

function TextInputWithFocusButton() {
  const inputEl = useRef(null);
  const onButtonClick = () => {
    // `current` points to the mounted text input element
    inputEl.current.focus();
  };
  return (
    <>
      <input ref={inputEl} type="text" />
      <button onClick={onButtonClick}>Focus the input</button>
    </>
  );
}

但是，ref 对象并不是只能存储 dom 对象。它是一个通用容器。有些类似 类的实例属性。可以存储任意类型的值。eg:

function Timer() {
  const intervalRef = useRef();

  useEffect(() => {
    const id = setInterval(() => {
      // ...
    });
    intervalRef.current = id;
    return () => {
      clearInterval(intervalRef.current);
    };
  });

  // ...
}

useImperativeHandle​

概述：在使用 ref 时，可以使用 useImperativeHandle，选择特定的实例属性暴漏给父组件。

必须结合 forwardRef 使用

function FancyInput(props, ref) {
  const inputRef = useRef();
  useImperativeHandle(ref, () => ({
    focus: () => {
      inputRef.current.focus();
    }
  }));
  return <input ref={inputRef} ... />;
}
FancyInput = forwardRef(FancyInput);

// 在父组件中拿到的ref引用，是一个 { focus:Function } 的对象。

useLayoutEffect​

与 useEffect 类似，

useLayoutEffect 在 componentDidMount 和 componentDidUpdate 相同的阶段触发。

React 官方建议，优先使用 useEffect，只在使用 useEffect 遇到问题时，尝试使用 useLayoutEffect

useDebugValue​

备份一篇去年写的关于ts 使用的小文章。

1. Typescript 部分常用可能会被忽略的知识点​

1.1 类型获取​

1.1.1 typeof​

使用 typeof 获取变量类型

const Setting = {
  color: "red",
  font: "xxx",
  width: 100,
  height: 100,
  title: "xxxx",
};

type SettingType = typeof Setting;

function getPropX() {
  return "xxx";
}

type GetPropXType = typeof getPropX;
type GetPropXReturnType = ReturnType<typeof getPropX>;

1.1.2 索引类型查询操作符 keyof​

const Setting = {
  color: "red",
  font: "xxx",
  width: 100,
  height: 100,
  title: "xxxx",
};

// type SettingKey = 'color' | 'font' | 'width' | 'height' | 'title'
type SettingKey = keyof typeof Setting;

1.1.3 索引访问​

使用 typeName['propName'] 格式读取属性类型

interface Person {
  name: string;
  age: string;
  sex: "man" | "woman";
  job?: string;
  eat: (food: string) => void;
}

type eat = Person["eat"];

1.2 泛型的使用和定义​

泛型其实就是类型变量，根据传入的类型，获取到需要的类型

添加泛型的位置:

• 函数泛型 -- 在函数上添加泛型

• 类泛型 -- 在类上添加泛型

class GenericNumber<T> {
  zeroValue: T;
  add: (x: T, y: T) => T;
}

• 类型泛型 -- 在接口或类型别名(使用 type 或 interface 定义的类型)上添加泛型

// antd rowSelection 的类型
export interface TableRowSelection<T> {
  type?: RowSelectionType;
  selectedRowKeys?: Key[];
  onChange?: (selectedRowKeys: Key[], selectedRows: T[]) => void;
  getCheckboxProps?: (record: T) => Partial<Omit<CheckboxProps, "checked" | "defaultChecked">>;
  onSelect?: SelectionSelectFn<T>;
  onSelectMultiple?: (selected: boolean, selectedRows: T[], changeRows: T[]) => void;
  /** @deprecated This function is meaningless and should use `onChange` instead */
  onSelectAll?: (selected: boolean, selectedRows: T[], changeRows: T[]) => void;
  /** @deprecated This function is meaningless and should use `onChange` instead */
  onSelectInvert?: (selectedRowKeys: Key[]) => void;
  selections?: INTERNAL_SELECTION_ITEM[] | boolean;
  hideDefaultSelections?: boolean;
  fixed?: boolean;
  columnWidth?: string | number;
  columnTitle?: string | React.ReactNode;
  renderCell?: (
    value: boolean,
    record: T,
    index: number,
    originNode: React.ReactNode,
  ) => React.ReactNode | RcRenderedCell<T>;
}

// antd table columns 的类型
export declare type ColumnsType<RecordType = unknown> = (
  | ColumnGroupType<RecordType>
  | ColumnType<RecordType>
)[];

1.3 条件类型的使用和定义​

常用的条件类型

更过预定义的条件类型 typescript/lib/lib.d.ts

- Partial<T> -- 使 T 中的所有属性变成可选属性
- Pick<T,K extends keyof T> -- 从 T 中挑选属性 K，组成新的类型
- Omit<T, K extends keyof any> -- 从 T 中删除属性 K，组成新的类型
- ReturnType<T extends (...args: any) => any> -- 获取函数的返回值类型
- Required<T> -- 使 T 中的所有属性变成必选属性
- Readonly<T> -- 使 T 中的所有属性变成只读属性
- Exclude<T, U> -- 从 T 中剔除可以赋值给 U 的类型。
- Extract<T, U> -- 提取 T 中可以赋值给 U 的类型。
- NonNullable<T> -- 从 T 中剔除 null 和 undefined。
- ReturnType<T> -- 获取函数返回值类型。
- InstanceType<T> -- 获取构造函数类型的实例类型。

2. React 项目中的 Typescript​

此章节重点,类型定义和类型使用经验和小技巧

1. 使用 vscode 开发 typescript 时，强大的智能提示和自动导入以及自动修复功能的使用。

2. 类型的复用

2.1 自定修复和自动导入​

2.1.1 书写时的智能提示和导入​

跨文件，可导入的 类型 / 方法 / 变量 ...的智能提示，以及自动导入

2.1.2 自动 fix 的自动导入​

单个修复导入

所有修复导入

2.2 定义组件的 props 中的类型​

2.2.1 props 的 interface 定义位置​

props 的 interface 定义位置: 组件文件中

import * as React from "react";

interface IComNameProps {}

const ComName: React.FunctionComponent<IComNameProps> = (props) => {
  return <div>ComName</div>;
};

export default ComName;

2.2.2 导出可能会用到的类型（interface/type/enum）​

大部分组件的 props 的 interface, 可以使用 export 导出,方便在使用组件时，部分类型的使用(可以参考下一章节:传递组件 props 时，使用到的类型)。

export interface IComNameProps {}

2.2.3 使用和查找已定义的类型​

定义组件 props 属性时，引用类属性，优先考虑使用已定义的类型（善用 vsocde 强大的引用提示，以及自动引入功能）

import { Store } from "antd/lib/form/interface";
import { ResourceSaveDto } from "@/client/services/umgt/resource";

export interface PopupStore extends Store, ResourceSaveDto {}

2.3 传递组件 props 时，使用到的类型​

上面定义并导出好组件和组件的类型后，在使用此组件时，可同时引入可能用到的类型

大部分组件的 props 传递时，需要的数据类型，都可以通过鼠标放上去的提示来找到。

1. 直接使用和引入单个 props 属性类型
2. 引入整个组件 props 类型，使用 interfaceName['propsName]

2.4 Vsocde 中的重构​

2.4.1 引用查找​

2.4.2 引用重命名​

邮件重命名或者 F2 重命名

2.5 使用 code snippets​

给大家推荐的 React Ts Extension Pack 包里，包含了两个下载量比较大的 react 语法段的包

2.4.1 ES7 React/Redux/React-Native/JS snippets​

imp→	import moduleName from 'module'
imd→	import { destructuredModule } from 'module'
imr→	import React from 'react'

edf→	export default (params) => { }
cp→	const { } = this.props
cs→	const { } = this.state

------------------------------------------------------------------
rcc→
import React, { Component } from 'react'

export default class FileName extends Component {
  render() {
    return <div>$2</div>
  }
}

------------------------------------------------------------------
rcep→
import React, { Component } from 'react'
import PropTypes from 'prop-types'

export class FileName extends Component {
  static propTypes = {}

  render() {
    return <div>$2</div>
  }
}
-----------------------------------------------------------------
rafcp→
import React from 'react'
import PropTypes from 'prop-types'

const $1 = (props) => {
  return <div>$0</div>
}

$1.propTypes = {}

export default $1

export default $1

-----------------------------------------------------------------
rcredux→
import React, { Component } from 'react'
import { connect } from 'react-redux'

export class FileName extends Component {
  render() {
    return <div>$4</div>
  }
}

const mapStateToProps = (state) => ({})

const mapDispatchToProps = {}

export default connect(mapStateToProps, mapDispatchToProps)(FileName)

2.4.2 Typescript React Code snippets​

// tsrsfc	stateless functional component
import * as React from "react";

interface IAppProps {}

const App: React.FunctionComponent<IAppProps> = (props) => {};

export default App;
-----------------------------------------------------------------
// tsrcc→	class component skeleton
import * as React from "react";

export interface IAppProps {}

export default class App extends React.Component<IAppProps> {
  public render() {
    return <div />;
  }
}
-----------------------------------------------------------------
// tscntr→	react redux container skeleton
import * as React from "react";
import { connect } from "react-redux";

export interface IAppProps {}

class App extends React.Component<IAppProps> {
  public render() {
    return <div />;
  }
}

const mapState2Props = (state) => {
  return {};
};

export default connect(mapState2Props)(App);

3 React Redux 结合 Typescript​

Redux Typescript 基础写法

1. 如何定义类型
2. 何时定义类型
   1. 数据产生，和数据获取的地方。
   2. 比如定义请求函数的地方， 独立组件props的定义，都是经典且基础的需要定义类型的地方
3. 何时使用类型，即引用类型
   1. 数据使用的地方，数据关联的地方，这些地方，应该优先引用上述定义的类型，而无需重复定义类型。
   2. 例如使用请求来的数据的时候，使用请求函数定义时定义的类型
   3. 组件使用的时候，使用组件定义时定义的类型。
   4. 数据关联的地方，指比如两个接口，获取的数据有一定的包含关系，可以使用类型继承，来引用类型。

类型使用和定义，应该遵循，定义尽量少的类型，增加已定义类型的复用性原则。

除了这三个问题外，还有一个练习太少的问题，很多老的项目，并没有使用Ts 编写。那么除了自己的ts 练习项目外， 还可以在哪里熟悉 ts类型的写法呢。

这里向大家介绍一个可能很多人都见过，并且写过的东西， ------------------- JSDOC。 我们可以使用JSDOC, 定义各种类型，以及可以被vscode良好的支持，给出边界的类型代码提示。

下面这种注释，估计大部分前端开发者都见过，并且都写过，但可能了解的并不是很多。下面我们对JSDOC是什么， 以及有什么作用来做个介绍

/**
 * 函数Desc
 * @param {string} params1 
 * @param {number} params2 
 */
function name(params1, params2) {
    
}

JSDOC 介绍​

JSDoc是一个根据javascript文件中注释信息，生成JavaScript应用程序或库、模块的API文档 的工具。你可以使用他记录如：命名空间，类，方法，方法参数等。类似JavaDoc和PHPDoc。现在很多编辑器或IDE中还可以通过JSDoc直接或使用插件生成智能提示。从而使开发者很容易了解整个类和其中的属性和方法，并且快速知道如何使用，从而提高开发效率，降低维护成本。

是标记变量、入参、返回值的类型，稍微弥补了 JavaScript 没有静态类型，不支持类型标注的问题。基于 JSDoc 的类型注释，Google Closure Compiler 可以分析优化代码，VS Code 之类的代码编辑器可以在不使用 TypeScript 的情况下实现代码提示。

历史​

Michael Mathews 在 2001 年创建 JSDoc 项目，它是最早的 JavaScript 文档工具，注释语法借鉴自 Javadoc（很多文档工具都使用了类似 Javadoc 注释语法，比如 C++ 的 Doxygen、 PHP 的 phpDocumentor）。截止 2020 年经历了 4 个大版本更新：

• 2001 JSDoc (JSDoc.pm): 使用 Perl 编写，代码托管在 SourceForge
• 2007 JsDoc Toolkit 1.0: 使用 JavaScript 编写，基于 Rhino，运行在 Java 平台，代码托管在 Google Code
• 2008 JsDoc Toolkit 2.0: 同 1.0
• 2011 JSDoc 3: 基于 Node.js，代码托管在 GitHub

编译文档用法

npm i -g jsdoc 
jsdoc yourjavascriptfile.js

• 项目地址: https://github.com/jsdoc/jsdoc
• 语法文档: https://jsdoc.app/ http://www.dba.cn/book/jsdoc/

常用标注​

• 类型
  • @type
  • @typedef
  • @property/@prop
  • @template
  • @enum
• 函数
  • @param/@argument/@arg
  • @returns/@return
  • @throws
  • @deprecated
• 类和继承
  • @constructor/@class
  • @this
  • @extends
  • @public
  • @private
  • @protected
  • @readonly
• 文档
  • @fileoverview
  • @author
  • @example
  • @description
  • @see
  • @link
  • @license
  • @preserve

使用示例​

定义类型：

/**
 * desc desc desc
 * @typedef {string|number} TypeName
 * /
/**
 * desc desc desc
 * @typedef {Object} ObjectTypeName
 * @property {string} name
 * @property {number} age
 * /
 
/**
 * desc desc desc
 * @typedef {{
 * name:string;
 * age:number;
 * count: string | number;
 * }} ObjectTypeName
 * /

使用类型

/**@type {TypeName} **/
let a = '';


/**@type {ObjectTypeName} **/
let obj = {};

JSDOC 中类型和 Typescipt中类型的区别​

1. 不支持泛型。
2. JSDOC 本质就是注释， 无法支持， ts的类型检查。只能提供类型提示。

JSDOC 好处​

1. 注释更加规范化，
2. 让js 具备类型提示，代码提示。
3. 增加js代码可读性，可维护性。
4. 可以直接生成 api 文档。

使用JSDOC 的开源项目​

• loadash https://github.com/lodash/lodash
• axios https://github.com/axios/axios
• mathjs https://github.com/josdejong/mathjs
• ramda https://github.com/ramda/ramda

后续会补充模型使用、提示词和工程实践。

管理员启动 powershell

set-ExecutionPolicy RemoteSigned

关闭 powershell， 重新启动