摘要：即使中没有错误，仍然会执行，这一点一般都是知道的。我们认为这是正确的前进道路，兼具战略性和务实性降低使用门槛开发人员迁移到的障碍之一是从到的并不轻松的迁移。下一步将通过一系列功能和插件为的平滑过渡提供支持，并以此回馈社区。
useState vs useReducer
关于 finally 的一些特殊场景
TSLint in 2019
Screenshot To Code
优化 React App 性能的 5 个建议
禁用大体积依赖的 import
理解 TS 类型注解
Back/forward cache for Chrome
ES 新提案：Promise.any(promises)
为什么这个函数不能 new
函数组件和类组件的根本差异
Preact X Alpha 0 released
Chromium Edge 截图透出
React 函数组件的 TypeScript 写法
用 Jest 和 Enzyme 写测试
useState vs useReducer这两个内置的 React Hooks 都可以处理状态，那么我们应该如何对二者进行选择呢？
根据我个人的实践来看，在 H5 项目中，useReducer 可以很好的按照 Redux 的模式完成许多工作，同时又可以不引入 Redux 的依赖。那么大佬们是怎么说的呢？
Matt Hamlin 的文章 useReducer, don"t useState 对这个问题进行了讨论。在本文中，我们先来看下作者在他自己的项目中被问到的一个问题
我们来看看所谓的 Subscribe 组件的实现：
const [submitted, setSubmitted] = React.useState(false) const [loading, setLoading] = React.useState(false) const [response, setResponse] = React.useState(null) const [errorMessage, setErrorMessage] = React.useState(null)
是的，因为有了这么些状态，就不免相应的有很多调用状态更新方法的地方：
async function handleSubmit(values) {
setSubmitted(false)
setLoading(true)
try {
const responseJson = await fetch(/* stuff */).then(r => r.json())
setSubmitted(true)
setResponse(responseJson)
setErrorMessage(null)
} catch (error) {
setSubmitted(false)
setErrorMessage("Something went wrong!")
}
setLoading(false)
}
可如果我们用 useReducer 重写上面的逻辑，就会变成下面这样：
const [state, dispatch] = React.useReducer(reducer, {
submitted: false,
loading: false,
response: null,
errorMessage: null,
})
而 reducer 的实现就像下面这样：
const types = {
SUBMIT_STARTED: 0,
SUBMIT_COMPLETE: 1,
SUBMIT_ERROR: 2,
};
function reducer(state, action) {
switch (action.type) {
case types.SUBMIT_STARTED: {
return { ...state, submitted: false, loading: true };
}
case types.SUBMIT_COMPLETE: {
return {
...state,
submitted: true,
response: action.response,
errorMessage: null,
loading: false,
};
}
case types.SUBMIT_ERROR: {
return {
...state,
submitted: false,
errorMessage: action.errorMessage,
loading: false,
};
}
default: {
return state;
}
}
}
相应的 handleSubmit 方法就可以调整为：
async function handleSubmit(values) {
dispatch({ type: types.SUBMIT_STARTED });
try {
const responseJson = await fetch(/* stuff */).then(r => r.json());
dispatch({ type: types.SUBMIT_COMPLETE, response: responseJson });
} catch (error) {
dispatch({ type: types.SUBMIT_ERROR, errorMessage: "Something went wrong!" });
}
}
Matt Hamlin 在他的文章中列举了如下几点来表明 useReducer 相比 useState 的优越性：
更容易管理较大较复杂的状态
更容易被其他开发者所理解
更容易测试
对于上面这种特定的例子，作者并不觉得第一条和第二条真的成立。只是 4 个状态元素很难说就是个大的复杂的状态，而且前后似乎也看不出有什么更容易理解。作者认为这两种写法是一样的。
至于测试，作者表示绝对同意 reducer 更容易读力测试，如果有很多业务逻辑，这确实是个很好的优势。
在作者看来，有一个原因他会更愿意使用 useState：
当我们并不确定一个组件的具体实现同时我们需要构建这一组件的时候。
当我们构建一个新的组件，我们经常需要在组件的实现代码中添加/删除状态。作者认为，面对这种情况，reducer 的写法调整起来会更加麻烦。一旦你确定了你希望你的组件是什么样的，你就可以决定是否从若干个 useState 的写法转换成一个 useReducer 来写。此外，你也可以考虑使用 useReducer 来实现其中的一部分，并使用 useState 来实现其他部分的逻辑。作者认为，等到确定代码究竟要调整成什么样子时再开始抽象会更好一些。
总的来说，二者自然是兼具优点与缺点的，具体还是得看要怎么用。结合我自己的实践，我发觉文中的意思乍看有些废话，但实际上是有道理的。在我使用 useState 写完之后确定了逻辑，就会开始觉得 useState 的写法有些凌乱，此时在已经确定了各个状态的情况下，再调整成 useReducer 就水到渠成了。
源地址：https://kentcdodds.com/blog/s...
关于 finally 的一些特殊场景今天我们来看下 finally 在一些特殊场景下的行为。
场景列举 在 catch 中 throw如果我们在 catch 块中抛出一个异常，且异常没有相应的 catch 来捕获，会发生什么情况呢？
function example() {
try {
fail()
}
catch (e) {
console.log("Will finally run?")
throw e
}
finally {
console.log("FINALLY RUNS!")
}
console.log("This shouldn"t be called eh?")
}
example()
finally 会执行，即使最后一句 console 并没有。finally 是比较特殊的，它使得我们可以执行在抛出异常和离开函数之间的东西，即使异常本身是在 catch 块中抛出的。
没有 catch 的情况如果没有 catch，finally 又会有怎样的行为呢？当然这一点一般都知道。
function example() {
try {
console.log("Hakuna matata")
}
finally {
console.log("What a wonderful phrase!")
}
}
example()
即使 try 中没有错误，finally 仍然会执行，这一点一般都是知道的。当然，如果有错误，那么 finally 也是会执行的。也就是说，finally 会覆盖这两种情况，如下：
try 中 return 的 finally如果我们没有出现错误，并且只是 return 了，会怎么执行呢？
function example() {
try {
console.log("I"m picking up my ball and going home.")
return
}
finally {
console.log("Finally?")
}
}
example()
总结
finally 总会执行，即使因为抛出异常或执行 return 而提前结束。
这样就让其非常有用，当我们有无论如何都要执行的东西时，放在 finally 就总是可以执行，例如 cleanup 等等。
源地址：https://frontarm.com/james-k-...
TSLint in 2019Palantir 是 TSLint 的创建及主要维护团队，而 TSLint 是 TypeScript 的标准 linter。由于 TypeScript 社区致力于统一 TypeScript 和 JavaScript 的开发体验，因而作者他们支持 TSLint 和 ESLint 的融合工作。在这篇博文中，他们解释了这样做的原因并阐述了如何去做。
TSLint 与 ESLint 的现状如今，TSLint 已经是事实上的用 TypeScript 实现的项目和 TypeScript 自身实现的标准 linter。 TSLint 生态系统由核心规则集、社区维护的自定义规则和配置包组成。
与之相对的是，ESLint 是标准的 JavaScript linter。和 TSLint 一样，它由核心规则集和社区维护的自定义规则组成。 ESLint 支持 TSLint 缺少的许多功能，例如条件 lint 配置和自动缩进。与之相对的是，ESLint 规则不能（至少现在不能）从 TypeScript 提供的静态分析和类型推理中受益，因此无法捕获 TSLint 语义规则所涵盖的一类错误和代码嗅探。
TypeScript + ESLintTypeScript 团队的战略方向（Roadmap）是为了实现「每家每户每个 JavaScript 程序员都可以用上类型」，哈哈哈搞笑。换句话说，他们的方向是使用类型和静态分析等 TypeScript 功能，渐进式的丰富 JavaScript 开发人员的体验，直到 TypeScript 和 JavaScript 开发人员体验融合统一为止。
很明显，linting 是 TypeScript 和 JavaScript 开发人员使用体验的一个核心部分，因此 Palantir 的 TSLint 团队与 Redmond 的 TypeScript 核心团队会面，讨论 TypeScript / JavaScript 的融合之于 linting 的意义。TypeScript 社区旨在满足 JavaScript 开发人员的需求，ESLint 是 JavaScript linting 的首选工具。我们计划弃用 TSLint，集中精力为 ESLint 改进 TypeScript 支持。我们认为这是正确的前进道路，兼具战略性和务实性：
降低使用门槛
JavaScript 开发人员迁移到 TypeScript 的障碍之一是从 ESLint 到 TSLint 的并不轻松的迁移。允许开发人员从他们现有的 ESLint 设置开始，逐步添加 TypeScript 特定的静态分析可以减少这一障碍。
统一社区
ESLint 和 TSLint 共同的核心目标是：通过强大的核心规则集和大量插件提供出色的代码 linting 体验。现在，在 ESLint 中可以使用 TypeScript 解析，我们认为社区最好能够做到标准化，而不是在竞争中维护不同的代码。
性能更好的分析架构
ESLint API 允许更有效地实现某些类检查。虽然可以重构 TSLint 的 API，但是利用 ESLint 的架构并将我们的开发资源集中在其他地方似乎是明智的。
下一步Palantir 将通过一系列功能和插件为 ESLint 的平滑过渡提供支持，并以此回馈 TSLint 社区。例如：
在 TypeScript 中使用 ESLint 规则的支持及文档：issue。
typescript-eslint 的测试架构：ESLint 内置的检查并不好用，且语法很难阅读。我们想要带来类似TSLint’s testing infrastructure 的东西以确保 TSLint 规则的开发体验。
语义化的基于类型的检查规则：移植并添加使用 TypeScript 语言服务的新规则。
一旦我们认为，ESLint 已经参照 TSLint 完成了各个特性，我们就会废弃 TSLint 并帮助用户迁移到 ESLint。我们总结下目前的主要任务是：
继续 TSLint 的支持：最重要的维护任务是确保新的变异版本和特性的兼容性。
TSLint -> ESLint 兼容包：一旦 ESLint 的静态分析检查可以与 TSLint 相提并论，我们就会推出 eslint-config-palantir 包，一个插入式的替代 TSLint 规则的 ESLint 包。
源地址：https://medium.com/palantir/t...
Screenshot To Code从设计稿变前端代码的故事已经说了很久，而这两天再次更新的 Screenshot To Code 是除了 pix2code 等之外的更让人兴奋的模型。
看看效果我们来看下整个三步走，首先是将设计稿传入训练好的网络模型（图中其实是在 Jupyter Notebook 里执行 python 脚本）：
然后模型就会将图片转换成 HTML 标签：
还是很骚的哈。最后渲染出来的静态页面如下，看上去效果很酷啊，不过我们也都知道，展示效果嘛。
简单分析框架使用的还是 Keras，然后仓库中提供了 HTML 和 Bootstrap 版本。具体核心逻辑可以参考这篇文章，笔者尚未深入研读，这里就不秀了。
大致的意思是，HTML 标签的输出，是以一个标签和 screenshoot 为输入得到下一个标签，然后再以已有的标签再去推测后续的标签。
这种思路是借鉴了一个 word 跟着一个 word 的预测，因此网络模型中也大量用到了 LSTM。
还是可以再了解了解这块东西的，晚点再深入读来看看。
源地址：https://yuque.antfin-inc.com/...
优化 React App 性能的 5 个建议本篇将从 render 角度来探讨 5 个 React App 的优化技巧。需要声明的是，文中将涉及部分 React 16.8.2 的内容，也就是说会有些 Hooks 相关内容。当然，这不是全部，不过理解了 React Hooks 后食用效果更佳。
当我们讨论 React App 的性能问题时，不可避免的就是要探讨我们的组件渲染的有多快。在进入到具体优化建议之前，我们先要理解以下 3 点：
当我们在说「渲染」时，我们在说什么？
什么时候会有「渲染」？
在「渲染」过程中会发生什么？
关于 render 函数这部分我们将从一种更简单的方式来理解 reconciliation 和 diffing 的概念，当然文档在这里。
哪个是 render 函数？这个问题其实写过 React 的人都会知道，这里简单说下：
在 class 组件中，指的是 render 方法：
class Foo extends React.Component {
render() {
return Foo
;
}
}
在函数式组件中，我们指的是函数组件本身：
function Foo() {
return Foo
;
}
render 什么时候会执行？
render 函数会在两种场景下被调用：
1. 状态更新时import React from "react";
import ReactDOM from "react-dom";
class App extends React.Component {
render() {
return {count}
);
}
}
const rootElement = document.getElementById("root");
ReactDOM.render(
可以看到，代码中的逻辑是我们点击就会更新 count，到 10 以后，就会维持在 10。增加一个 console.log，这样我们就可以知道 render 是否被调用了。
总结：继承了 React.Component 的 class 组件，即使状态没变化，只要调用了setState 就会触发 render。
我们用函数实现相同的组件，当然因为要有状态，我们用上了 useState hook：
import React, { useState } from "react";
import ReactDOM from "react-dom";
class App extends React.Component {
render() {
return {count}
);
}
const rootElement = document.getElementById("root");
ReactDOM.render(
我们可以注意到，当状态值不再改变之后，render 的调用就停止了。
总结：对函数式组件来说，状态值改变时会触发 render 函数的调用。
2. 父容器重新渲染时import React from "react";
import ReactDOM from "react-dom";
class App extends React.Component {
state = { name: "App" };
render() {
return (
Foo
);
}
const rootElement = document.getElementById("root");
ReactDOM.render(
只要点击了 App 组件内的 Change name 按钮，就会重新 render。而且可以注意到，不管 Foo 具体实现是什么，Foo 都会被重新渲染。
总结：无论组件是继承自 React.Component 的 class 组件还是函数式组件，只要父容器重新 render 了，组件的 render 都会被再次调用。
render 函数执行时发生了什么？只要 render 函数被调用，就会有两个步骤按顺序执行。这两个步骤非常重要，理解了它们才好知道如何去优化 React App。
Diffing在此步骤中，React 将新调用的 render 函数返回的树与旧版本的树进行比较，这一步是 React 决定如何更新 DOM 的必要步骤。虽然 React 使用高度优化的算法执行此步骤，但仍然需要付出一定性能开销。
Reconciliation基于 diffing 的结果，React 更新 DOM 树。这一步同样要因为卸载和挂载 DOM nodes 带来了许多的性能开销。
Tip Tip #1：慎重分配 state 以避免不必要的 render 调用我们以下面的例子为例，其中 App 会渲染两个组件：
CounterLabel，接收 count 值和一个增加父组件 App 中的状态 count 的值的方法。
List，接收 item 的列表。
import React, { useState } from "react";
import ReactDOM from "react-dom";
const ITEMS = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12];
function App() {
const [count, setCount] = useState(0);
const [items, setItems] = useState(ITEMS);
return (
setCount(count + 1)} />
);
}
function CounterLabel({ count, increment }) {
return (
<>
{count}
);
}
function List({ items }) {
console.log("List render");
return (
只要父组件 App 中的状态被更新，CounterLabel 和 List 就都会更新。
当然，CounterLabel 重新渲染是正常的，因为 count 发生了变化，自然要重新渲染。但是对于 List 而言，就完全是不必要的更新了，因为它的渲染是独立于 count 值的。尽管 React 并不会在 reconciliation 阶段真的更新 DOM，毕竟完全没变化，但是仍然会执行 diffing 阶段来对前后的树进行对比，这仍然存在性能开销。
还记得 render 执行的 diffing 和 reconciliation 阶段吗？前面讲过的东西在这里碰到了。
因此，为了避免不必要的 diffing 开销，我们应当考虑将特定的状态值放到更低的层级或组件中（与 React 中所说的「提升」概念正好相反）。在这个例子中，我们就是要将 count 值放到 CounterLabel 组件中管理来解决这个问题。
Tip #2：合并状态更新因为每次状态更新都会触发新的 render 调用，那么更少的状态更新也就可以更少的调用 render 了。
我们知道，React class 组件有 componentDidUpdate(prevProps, prevState) 的钩子，可以用来检测 props 或 state 有没有发生变化。尽管有时有必要在 props 发生变化时再触发 state 更新，但我们总可以避免在一次 state 变化后再进行一次 state 更新这种操作：
import React from "react";
import ReactDOM from "react-dom";
function getRange(limit) {
let range = [];
for (let i = 0; i < limit; i++) {
range.push(i);
}
return range;
}
class App extends React.Component {
state = {
numbers: getRange(7),
limit: 7
};
handleLimitChange = e => {
const limit = e.target.value;
const limitChanged = limit !== this.state.limit;
if (limitChanged) {
this.setState({ limit });
}
};
componentDidUpdate(prevProps, prevState) {
const limitChanged = prevState.limit !== this.state.limit;
if (limitChanged) {
this.setState({ numbers: getRange(this.state.limit) });
}
}
render() {
return (
{this.state.numbers.map((number, idx) => (
{number}
))}
);
}
}
const rootElement = document.getElementById("root");
ReactDOM.render(
这里渲染了一个范围的数字序列，范围为 0 到 limit。只要用户改变了 limit 值，我们就会在 componentDidUpdate 中进行检测，并设定新的数字列表。
毫无疑问，上面的代码是可以满足需求的，但是，我们仍然可以进行优化。
上面的代码中，每次 limit 发生改变，我们都会触发两次状态更新：第一次是为了修改 limit，第二次是为了修改展示的数字列表。这样一来，每次 limit 的变化会带来两次 render 开销：
// 初始状态
{ limit: 7, numbers: [0, 1, 2, 3, 4, 5, 6]
// 更新 limit -> 4
render 1: { limit: 4, numbers: [0, 1, 2, 3, 4, 5, 6] } //
render 2: { limit: 4, numbers: [0, 2, 3]
我们的代码逻辑带来了下面的问题：
我们触发了比实际需要更多的状态更新；
我们出现了「不连续」的渲染结果，数字列表与 limit 不匹配。
为了改进，我们应避免在不同的状态更新中改变数字列表。事实上，我们可以在一次状态更新中搞定：
import React from "react";
import ReactDOM from "react-dom";
function getRange(limit) {
let range = [];
for (let i = 0; i < limit; i++) {
range.push(i);
}
return range;
}
class App extends React.Component {
state = {
numbers: [1, 2, 3, 4, 5, 6],
limit: 7
};
handleLimitChange = e => {
const limit = e.target.value;
const limitChanged = limit !== this.state.limit;
if (limitChanged) {
this.setState({ limit, numbers: getRange(limit) });
}
};
render() {
return (
{this.state.numbers.map((number, idx) => (
{number}
))}
);
}
}
const rootElement = document.getElementById("root");
ReactDOM.render(
Tip #3：使用 PureComponent 和 React.memo 以避免不必要的 render 调用
我们在之前的例子中看到将特定状态值放到更低的层级来避免不必要渲染的方法，不过这并不总是有用。
我们来看下下面的例子：
import React, { useState } from "react";
import ReactDOM from "react-dom";
function App() {
const [isFooVisible, setFooVisibility] = useState(false);
return (
{isFooVisible ? (
setFooVisibility(false)} />
) : (
)}
);
}
function Foo({ hideFoo }) {
return (
<>
Foo
);
}
function Bar({ name }) {
return {name}
;
}
const rootElement = document.getElementById("root");
ReactDOM.render(
可以看到，只要父组件 App 的状态值 isFooVisible 发生变化，Foo 和 Bar 就都会被重新渲染。
这里因为需要决定 Foo 是否要被渲染出来，我们需要将 isFooVisible 放在 App中维护，因此也就不能将状态拆除放到更低的层级。不过，在 isFooVisible 发生变化时重新渲染 Bar 仍然是不必要的，因为 Bar 并不依赖 isFooVisible。我们只希望 Bar 在传入属性 name 变化时重新渲染。
那我们该怎么搞呢？两种方法。
其一，对 Bar 做记忆化（memoize）：
const Bar = React.memo(function Bar({name}) {
return {name}
;
});
这就能保证 Bar 只在 name 发生变化时才重新渲染。
此外，另一个方法就是让 Bar 继承 React.PureComponent 而非 React.Component：
class Bar extends React.PureComponent {
render() {
return {name}
;
}
}
是不是很熟悉？我们经常提到使用 React.PureComponent 能带来一定的性能提升，避免不必要的 render。
总结：避免组件不必要的渲染的方法有：React.memo 包起来的函数式组件，继承自 React.PureComponent 的 class 组件。
为什么不让每个组件都继承 PureComponent 或者用 memo 包呢？如果这条建议可以让我们避免不必要的重新渲染，那我们为什么不把每个 class 组件变成 PureComponent、把每个函数式组件用 React.memo 包起来？为什么有了更好的方法还要有 React.Component 呢？为什么函数式组件不默认记忆化呢？
毫无疑问，这些方法并不总是万灵药呀。
我们先来考虑下 PureComponent 和 React.memo 的组件到底做了什么？
每次更新的时候（包括状态更新或上层组件重新渲染），它们就会在新 props、state 和旧 props、state 之间对 key 和 value 进行浅比较。浅比较是个严格相等的检查，如果检测到差异，render 就会执行：
// 基本类型的比较
shallowCompare({ name: "bar"}, { name: "bar"}); // output: true
shallowCompare({ name: "bar"}, { name: "bar1"}); // output: false
尽管对于基本类型（如字符串、数字、布尔）的比较工作的很好，如对象这类复杂的值可能就会带来意想不到的行为：
shallowCompare({ name: {first: "John", last: "Schilling"}},
{ name: {first: "John", last: "Schilling"}}); // output: false
上述两个 name 对象的引用是不同的。
我们重新看下之前的例子，然后修改我们传入 Bar 的 props：
import React, { useState } from "react";
import ReactDOM from "react-dom";
const Bar = React.memo(function Bar({ name: { first, last } }) {
console.log("Bar render");
return (
{first} {last}
);
});
function Foo({ hideFoo }) {
return (
<>
Foo
);
}
function App() {
const [isFooVisible, setFooVisibility] = useState(false);
return (
{isFooVisible ? (
setFooVisibility(false)} />
) : (
)}
);
}
const rootElement = document.getElementById("root");
ReactDOM.render(
尽管 Bar 做了记忆化且 props 值并没有发生变动，每次父组件重新渲染时它仍然会重新渲染。这是因为每次比较的两个对象尽管拥有相同的值，却因为浅比较的引用不同触发重新渲染。
我们也可以把函数作为属性向组件传递，当然，在 JavaScript 中函数也是传递的引用，因此浅比较也是基于其传递的引用。
因此，如果我们传递的是箭头函数（匿名函数），组件仍然会在父组件重新渲染时重新渲染。
Tip #4：更好的 props 写法前面的问题的一种解决方法是改写我们的 props。
我们不传递对象作为 props，而是将对象拆分成基本类型：
而对于传递箭头函数的场景，我们可以代以只唯一声明过一次的函数，从而总可以拿到相同的引用，如下所示：
class App extends React.Component{
constructor(props) {
this.doSomethingMethod = this.doSomethingMethod.bind(this);
}
doSomethingMethod () { // do something}
render() {
return
Tip #5：控制更新
还是那句话，任何方法总有其适用范围。
第三条建议虽然处理了不必要的更新问题，但我们也不总能使用它。
而第四条，在某些情况下我们并不能拆分对象，如果我们传递了某种嵌套确实复杂的数据结构，那我们也很难将其拆分开来。
不仅如此，我们并不总能传递只声明了一次的函数。比如在我们的例子中，如果 App 是个函数式组件，恐怕就不能做到这一点了（在 class 组件中，我们可以用 bind 或者类内箭头函数来保证 this 的指向及唯一声明，而在函数式组件中则可能会导致一些问题）。
幸运的是，无论是 class 组件还是函数式组件，我们都有办法控制浅比较的逻辑。
在 class 组件中，我们可以使用生命周期钩子 shouldComponentUpdate(prevProps, prevState) 来返回一个布尔值，当返回值为 true 时才会触发 render。
而如果我们使用 React.memo，我们可以传递一个比较函数作为第二个参数。
注意！React.memo 的第二参数（比较函数）和 shouldComponentUpdate 的逻辑是相反的，只有当返回值为 false 的时候才会触发 render。参考文档。
const Bar = React.memo(
function Bar({ name: { first, last } }) {
console.log("update");
return (
{first} {last}
);
},
(prevProps, newProps) =>
prevProps.name.first === newProps.name.first &&
prevProps.name.last === newProps.name.last
);
尽管这条建议是可行的，但我们仍要注意比较函数的性能开销。如果 props 对象过深，反而会消耗不少的性能。
总结上述场景仍不够全面，但多少能带来一些启发性思考。当然我们还有许多其他的问题需要考虑，但遵守上述的准则仍能带来相当不错的性能提升。
源地址：https://medium.com/@siffogh3/...
禁用大体积依赖的 importAddy Osmani 大佬推荐了一个 ESLint 的方法来达成这一效果。
有时候我们可能在团队的项目中禁用大体积依赖包的引入，而这一点我们可以借助 ESLint 来指定项目中不引用特定的依赖来做到，也即 no-restricted-modules 规则。
如下的例子展示的是禁用 moment.js 的引入（这类体积大的直接引用的话肯定就爆了，不过我们也常常会考虑按需加载）。这条规则也支持自定义提示信息，所以错误提示可以建议大家使用小一些的包来代替，如 date-fns、Luxon 等。
{
"rules": {
"no-restricted-imports": ["error", {
"paths": [{
"name": "moment",
"message": "Use date-fns or Luxon instead!"
}]
}]
}
}
这样一来，当团队中有人尝试着如下写法，就会报错：
import moment from "moment";
另一个例子是禁用 lodash：
{
"rules": {
"no-restricted-imports": ["error", {
"name": "lodash",
"message": "Use lodash-es instead!",
}],
}
}
当然，我们也可以不适用错误提示，一个数组搞定：
{
"rules": {
"no-restricted-imports": ["error", "underscore", "bluebird"]
}
}
当然，还有一些高级用法，no-restricted-modules 还支持类似 .gitignore 风格的模式。例如，如果有人尝试着引入匹配了 legacy/* 模式的包，我们就会报错，如 import helpers from "legacy/helpers"; 这种：
{
"rules": {
"no-restricted-imports": ["error", {
"patterns": ["legacy/*"]
}],
}
}
源地址：https://addyosmani.com/blog/d...
理解 TS 类型注解这篇文章来自 Dr. Axel Rauschmayer 的博客，对 TypeScript 的静态类型注解进行了梳理。今天来学习下。
1. 我们会学到什么在读完本篇文章后，我们应该能够理解下面这段代码的含义：
