2021前端应该掌握的干货

答神
1,462 阅读12分钟

一、前言

随着NodeJS的出现，JavaScript从以前的浏览器端可以运行到服务端,推进了前端工程师向全栈发展的新时代。

二、前端基础

2.1 NodeJS安装

Node.js 就是运行在服务端的 JavaScript。 Node.js 是一个基于Chrome JavaScript 运行时建立的一个平台。 Node.js是一个事件驱动I/O服务端JavaScript环境，基于Google的V8引擎，V8引擎执行Javascript的速度非常快，性能非常好。

安装

  • 官网下载安装包安装
  • NVM安装

配置

这里的环境配置主要配置的是npm安装的全局模块所在的路径，以及缓存cache的路径，之所以要配置，是因为以后在执行类似：npm install xxx [-g] （后面的可选参数-g，g代表global全局安装的意思）的安装语句时，会将安装的模块安装到【C:\Users\用户名\AppData\Roaming\npm】路径中，占C盘空间。我们希望将全模块所在路径和缓存路径放在我node.js安装的文件夹中，则在我安装的文件夹【D:\nodejs】下创建两个文件夹【node_global】及【node_cache】

  • 创建完两个空文件夹之后，打开cmd命令窗口，输入
npm config set prefix "D:\nodejs\node_global" 
npm config set cache "D:\nodejs\node_cache"
  • 然后点击“我的电脑”-右键-“属性”-“高级系统设置”-“高级”-“环境变量”在【系统变量】下新建【NODE_PATH】，输入【D:\nodejs\node_global\node_modules】，将【用户变量】下的【Path】修改为【D:\nodejs\node_global】
  • 配置后你可以在C:\Users\xxx\AppData\Local\Yarn\Data\global中查看到对应的配置

测试

  • 通过npm config list 获取npm配置信息
  • 配置完后，全局安装module测试下

2.2 包管理工具

说到包管理工具就要提到Node自带的NPM(Node Package Manager)包管理工具，在安装Node的时候，已经为你安装好了默认的包管理工具NPM,NPM的出现离不开社区文化，社区文化的意思是：拥有共同职业或兴趣的人群，自发组织在一起，通过分享信息和资源进行合作与交流。虚拟社区的参与者经常会在线讨论相关话题，或访问某些网站。世界上最大的前端社区应该就是 GitHub 了。前端通过 GitHub 来分享源代码（线上代码仓库） 也会通过问题清单（Issue列表），是一个收集学习资源的网站。加入社区最大的好处之一是，你可以使用别人贡献的代码，你也可以贡献代码给别人用。一个解决方案：用一个工具把这些代码集中到一起来管理吧！这个工具就是他用 JavaScript （运行在 Node.js 上）写的 npm，全称是 Node Package Manager。主流包管理工具包括npm、yarn、cnpm、pnpm几种类型。

npm

npm 是 Node.js 能够如此成功的主要原因之一。npm 团队做了很多的工作，以确保 npm 保持向后兼容，并在不同的环境中保持一致。npm使用一个名为package.json的文件，用户可以通过npm install --save命令把项目里所有的依赖项保存在这个文件里。

格式定义： 主版本号.次版本号.补丁版本号， 以下这三种情况需要增加相应的版本号：

  • 主版本号： 当API发生改变，并与之前的版本不兼容的时候
  • 次版本号： 当增加了功能，但是向后兼容的时候
  • 补丁版本号：当做了向后兼容的缺陷修复的时候 安装

你的电脑安装Node.js后会同时安装 npm 使用

npm install --save xxx

解析

  • ^字符，告诉npm，安装主版本等于主版本的任意一个版本即可
  • @是npm约定用来确定包名的指定版本的
  • @latest安装最新版本的包
  • 理论上，次版本号的变化并不会影响向后兼容性。因此，安装最新版的依赖库应该是能正常工作的，而且能引入自次版本和补丁版本是重要错误和安全方面的修复。
  • 即使使用了相同的package.json文件，在他们自己的机器上也可能会安装同一个库的不同种版本，为了保证安装相同的版本，需要生成package-lock.json文件来保证安装统一。

命令

  • npm init 创建项目
  • npm install 安装依赖包
  • npm list 枚举当前项目使用的依赖包
  • npm search 搜索依赖包
  • npm adduser 添加用户
  • npm login 登录npmjs.org
  • npm doctor 验证npm环境是否成功
  • npm publish 发布包
  • npm pack 打包

cnpm

  • cnpm跟npm用法完全一致，只是在执行命令时将npm改为cnpm。
  • npm安装插件是从国外服务器下载，受网络影响大，可能出现异常，如果npm的服务器在中国就好了，于是淘宝团队干了这事。来自官网：“这是一个完整 npmjs.org 镜像，你可以用此代替官方版本(只读)，同步频率目前为 10分钟 一次以保证尽量与官方服务同步。”
  • 官方地址：npm.taobao.org
  • 安装：$ npm install -g cnpm --registry=registry.npm.taobao.org

yarn

Yarn发布于2016年10月，截至当前2018年7月，在Github上拥有了32.2k个Star。而npm只有16.8k个Start。这个项目由一些高级开发人员维护，包括了Sebastian McKenzie（Babel.js）和Yehuda Katz（Ember.js、Rust、Bundler等）。

Yarn一开始的主要目标是解决上一节中描述的由于语义版本控制而导致的npm安装的不确定性问题。虽然可以使用npm shrinkwrap来实现可预测的依赖关系树，但它并不是默认选项，而是取决于所有的开发人员知道并且启用这个选项。

Yarn采取了不同的做法。每个yarn安装都会生成一个类似于npm-shrinkwrap.json的yarn.lock文件，而且它是默认创建的。除了常规信息之外，yarn.lock文件还包含要安装的内容的校验和，以确保使用的库的版本相同。

yarn是经过重新设计的崭新的npm客户端，它能让开发人员并行处理所有必须的操作，并添加了一些其他改进。

  • 运行速度得到了显著的提升，整个安装时间也变得更少
  • 像npm一样，yarn使用本地缓存。与npm不同的是，yarn无需互联网连接就能安装本地缓存的依赖项，它提供了离线模式。这个功能在2012年的npm项目中就被提出来过，但一直没有实现。
  • 允许合并项目中使用到的所有的包的许可证

pnpm

可阅读pnpm的作者Zoltan Kochan发表的“为什么要用pnpm？”

  • pnpm运行起来非常的快，超过了npm和yarn
  • pnpm采用了一种巧妙的方法，利用硬链接和符号链接来避免复制所有本地缓存源文件，这是yarn的最大的性能弱点之一
  • 使用链接并不容易，会带来一堆问题需要考虑。
  • pnpm继承了yarn的所有优点，包括离线模式和确定性安装

2.3 NPX

npx是一个工具，npm v5.2.0引入的一条命令（npx），一个npm包执行器，指在提高从npm注册表使用软件包时的体验 ，npm使得它非常容易地安装和管理托管在注册表上的依赖项，npx使得使用CLI工具和其他托管在注册表。它大大简化了一些事情。

就像npm极大地提升了我们安装和管理包依赖的体验，在npm的基础之上，npx让npm包中的命令行工具和其他可执行文件在使用上变得更加简单。它极大地简化了我们之前使用纯粹的npm时所需要的大量步骤。

  • 临时安装可执行依赖包，不用全局安装，不用担心长期的污染。

  • 可以执行依赖包中的命令，安装完成自动运行。

  • 自动加载node_modules中依赖包，不用指定$PATH。

  • 可以指定node版本、命令的版本，解决了不同项目使用不同版本的命令的问题。

2.4 TypeScript安装

在TypeScript项目中，TypeScript最终都会被编译JavaScript文件执行，TypeScript编译器在编译TypeScript文件的时候都会先在项目根目录的tsconfig.json文件，根据该文件的配置进行编译，默认情况下，如果该文件没有任何配置，TS编译器会默认编译项目目录下所有的.ts、.tsx、.d.ts文件。实际项目中，会根据自己的需求进行自定义的配置，下面就来详细了解下TypeScript项目的创建和tsconfig.json的文件配置。

安装

  • 全局安装npm install -g typescript@latest ||cnpm i -g t typescript@latest || npm i typescript@latest || yarn add -g typescript@latest
  • 局部安装``npm install typescript@latest ||cnpm i typescript@latest || npm i typescript@latest || yarn add typescript@latest`
  • 检测安装是否成功： tsc -v
  • 编译： tsc index.ts

生成tsconfig.json

安装完TypeScript在项目根目录下终端运行tsc --init或者npx tsc --init自动生成tsconfig.json文件。tsconfig.json是ts编译器的配置文件，ts可以根据它的信息来对代码进行编译。

  • 安装完TypeScript执行tsc --init报错
    • 解决方案: PowerShell的设置问题，脚本的默认执行策略 Restricted，禁止运行任何脚本和配置文件，需要管理员身份打开PowerShell： 使用get-executionpolicy 查看脚本执行策略，使用set-executionpolicy Restricted/RemoteSigned/Unrestricted/AllSigned，四种策略选其一，更改建议为RemoteSigned，执行命令set-executionpolicy RemoteSigned即可解决。
  • tsc --init执行时提示“无法将“tsc”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。
    • 解决方案： 将TypeScript安装到全局TypeScript,或者在本项目安装TypeScript后，使用npx tsc --init命令即可。

配置tsconfig.json

tsconfig.json主要有三个配置选项，分别是：文件选项配置、编译选项配置、工程引用配置。

  • 文件选项配置

    • files : 表示编译需要编译的单个指定文件列表，只有编译少量文件才使用

    • include: 表示编译需要编译的文件或目录【** : 任意目录 ， * : 任意文件】

    • exclude：表示编译器需要排除的文件或文件夹，除了指定的文件，其他文件都编译，默认node_module

    • extends: 引入其他配置文件，用来指定继承的配置文件

    • compileOnSave:设置保存文件的时候自动编译，

    • removeComments:编译js代码时，不生成注释("module"下)

  • 编译选项配置

    • 基本选项

      • incremental:启用增量编译
      • target:用来指定 ECMAScript 编译之后版本目标【ES3' (default), 'ES5', 'ES2015', 'ES2016', 'ES2017', 'ES2018', 'ES2019', 'ES2020', 'ES2021', or 'ESNEXT'最新】
      • module:指定要使用模块标准【'none', 'commonjs', 'amd', 'system', 'umd', 'es2015', 'es2020', or 'ESNext'】
      • lib:指定要包含在编译中的库文件
      • allowJs:allowJs设置的值为true或false，用来指定是否允许编译js文件，默认是false，即不编译js文件
      • checkJs:值为true或false，用来指定是否检查和报告js文件中的错误，默认是false
      • jsx:指定jsx代码生成用于的开发环境:"preserve"、"response -native"或"react、'react-jsx' or 'react-jsxdev'
      • declaration:declaration的值为true或false，用来指定是否在编译的时候生成相应的".d.ts"声明文件。如果设为true，编译每个ts文件之后会生成一个js文件和一个声明文件。但是declaration和allowJs不能同时设为true
      • declarationMap：值为true或false，指定是否为声明文件.d.ts生成map文件
      • sourceMap: sourceMap的值为true或false，用来指定编译时是否生成.map文件
      • outFile: 用于指定将输出文件合并为一个文件，它的值为一个文件路径名。比如设置为"./dist/main.js"，则输出的文件为一个main.js文件。但是要注意，只有设置module的值为amd和system模块时才支持这个配置
      • outDir:用来指定输出文件夹，值为一个文件夹路径字符串，输出的文件都将放置在这个文件夹
      • rootDir:用来指定编译文件的根目录，编译器会在根目录查找入口文件，如果编译器发现以rootDir的值作为根目录查找入口文件并不会把所有文件加载进去的话会报错，但是不会停止编译
      • composite:是否编译构建引用项目
      • tsBuildInfoFile:指定用于存储增量编译信息的文件
      • removeComments:removeComments的值为true或false，用于指定是否将编译后的文件中的注释删掉，设为true的话即删掉注释，默认为false
      • noEmit:不生成编译文件，这个一般比较少用
      • importHelpers:importHelpers的值为true或false，指定是否引入tslib里的辅助工具函数，默认为false。
      • downlevelIteration:当target为'ES5' or 'ES3'时，为'for-of', spread, and destructuring'中的迭代器提供完全支持。
      • isolatedModules: isolatedModules的值为true或false，指定是否将每个文件作为单独的模块，默认为true，它不可以和declaration同时设定 。

    • 严格的类型检查选项

      • strict:strict的值为true或false，用于指定是否启动所有类型检查，如果设为true则会同时开启下面这几个严格类型检查，默认为false 。
      • noImplicitAny:noImplicitAny的值为true或false，如果我们没有为一些值设置明确的类型，编译器会默认认为这个值为any，如果noImplicitAny的值为true的话。则没有明确的类型会报错。默认值为false。
      • strictnullcheck:strictNullChecks为true时，null和undefined值不能赋给非这两种类型的值，别的类型也不能赋给他们，除了any类型。还有个例外就是undefined可以赋值给void类型。
      • strictFunctionTypes: strictFunctionTypes的值为true或false，用于指定是否使用函数参数双向协变检查。
      • strictBindCallApply:设为true后会对bind、call和apply绑定的方法的参数的检测是严格检测的
      • strictPropertyInitialization:设为true后会检查类的非undefined属性是否已经在构造函数里初始化，如果要开启这项，需要同时开启strictNullChecks，默认为false。
      • noImplicitThis:当this表达式的值为any类型的时候，生成一个错误。
      • alwaysStrict:alwaysStrict的值为true或false，指定始终以严格模式检查每个模块，并且在编译之后的js文件中加入"use strict"字符串，用来告诉浏览器该js为严格模式。

    • 附加检查

      • noUnusedLocals:用于检查是否有定义了但是没有使用的变量，对于这一点的检测，使用eslint可以在你书写代码的时候做提示，你可以配合使用。它的默认值为false
      • noUnusedParameters:用于检查是否有在函数体中没有使用的参数，这个也可以配合eslint来做检查，默认为false。
      • noImplicitReturns:用于检查函数是否有返回值，设为true后，如果函数没有返回值则会提示，默认为false。
      • noFallthroughCasesInSwitch:用于检查switch中是否有case没有使用break跳出switch，默认为false。
      • noUncheckedIndexedAccess:用于检查在索引签名结果中包含'undefined'，默认为false。
      • noImplicitOverride: 用于检查使用“override”修饰符标记派生类中的重写成员，默认为false。
      • noPropertyAccessFromIndexSignature: 用于检查需要索引签名中未声明的属性才能使用元素访问，默认为false。

    • 模块解析选项

      • moduleResolution:指定模块解析策略:"node"(node .js)或"classic"(TypeScript pre-1.6)。
      • baseUrl:基本目录来解析非绝对模块名。
      • path:一系列条目,这些条目将导入重新映射到相对于"baseUrl"的查找位置。
      • rootDirs:根文件夹列表,其组合内容表示运行时项目的结构。
      • typeRoots:包含类型定义的文件夹列表。
      • types:编译中包含的类型声明文件。
      • allowSyntheticDefaultImports:允许从没有默认导出的模块进行默认导入。这并不影响代码发出,只影响类型查询。
      • esModuleInterop:通过为所有导入创建名称空间对象,支持CommonJS和ES模块之间的互操作性。意味着"allowSyntheticDefaultImports"。
      • preserveSymlinks:不解析符号链接的实际路径。
      • allowUmdGlobalAccess:允许从模块访问UMD全局。

    • 源映射选项

      • sourceRoot: 指定调试器应该定位TypeScript文件而不是源位置的位置。
      • mapRoot:指定调试器应该定位映射文件的位置,而不是生成的位置。
      • inlineSourceMap:发出一个带有源映射的文件,而不是一个单独的文件。
      • inlineSources:在单个文件中,将源文件与源文件一起发出;需要设置’- inlineSourceMap’或’- sourceMap’ 。

    • 实验选项

      • experimentalDecorators: 支持对ES7 decorator的实验支持。
      • emitDecoratorMetadata: 启用了对为decorator发出类型元数据的实验性支持。

    • 高级选项

      • skipLibCheck:跳过声明文件的类型检查。
      • forceConsistentCasingInFileNames:不允许对同一文件的大小写不一致的引用。

  • 工程引用配置

    • references 指定工程引用依赖

使用tsconfig.json

//使用tsconfig.json配置，编译ts文件

tsc

编译

  • 每次修改index.ts文件的代码，都要手动执行：tsc index.ts，非常麻烦。

  • 下载VSCode

  • tsc --init创建tsconfig.json文件并进行配置

    • 编译选项配置 
      // tsconfig.json
{
  "compilerOptions": {
    "target": "esnext",
    "module": "esnext",
    "moduleResolution": "node",
    "strict": true,
    "jsx": "preserve",
    "sourceMap": true,
    "resolveJsonModule": true,
    "esModuleInterop": true,
    "lib": ["esnext", "dom"]
  },
  "include": ["src/**/*.ts", "src/**/*.d.ts", "src/**/*.tsx", "src/**/*.vue"]
}

  • 在VSCode点击终端，找到配置任务(编译时候我们选择tsc: 构建-tsconfig.json,开发时候我们选择tsc: 监视-tsconfig.json)

  • 在src目录下书写ts文件里写代码，保存后自动编译成js文件

运行

  • 安装node环境后的简单命令
// 运行js文件
node index.js
// 编译ts文件
tsc index.ts
// 运行ts文件
ts-node index.ts
// 监视模式，自动编译
tsc --watch index.ts
avatar
文章
阅读
粉丝
相关推荐
2024为什么前端都应该掌握Nextjs 或 Nuxtjs
56k阅读
 · 
366点赞
听说前端出大事儿了
381k阅读
 · 
1.5k点赞
中高级前端必须掌握的package.json最新最全指南
77k阅读
 · 
1.5k点赞
放心，前端死不了
149k阅读
 · 
1.4k点赞
2023前端面试题总结
150k阅读
 · 
2.1k点赞
六年前端面试报告
130k阅读
 · 
1.7k点赞
前端应该掌握的浏览器调试技巧
20k阅读
 · 
427点赞
前端人必须掌握的抓包技能
69k阅读
 · 
1.3k点赞
前端无痛刷新Token
117k阅读
 · 
1.6k点赞
最近两周出去面试遇到的面试题（前端初级、长更）
347k阅读
 · 
4.8k点赞

友情链接：