[article] fix typo

1 files changed, 1 insertions, 1 deletions

diff --git a/content/article/js-problem.md b/content/article/js-problem.md
index 1dd084ca..bc56baa0 100644
--- a/content/article/js-problem.md
+++ b/content/article/js-problem.md
@@ -197,7 +197,7 @@ JavaScript 是用来设计交互式网页的，必须加载 JavaScript 才能看
 
 由于 JavaScript 开发者非常喜欢使用框架，还非常喜欢引入各种依赖，用于解决鸡毛蒜皮的小事。*如果某天出现了专门输出 `Hello World` 的 JavaScript 库，我不会感到意外。*
 
-我不止一次听到经验丰富的前端开发者抱怨 JavaScript 的开发体验，许多工作几乎都是在更新、维护、升级依赖，以及升级依赖之后由于 API 变动，需要做的额外的适配工作。如果不做这些工作，项目可能在几个月之内就会过时，变得不可用。尽管锁定依赖版本号之后也能够继续使用旧版本，但一旦选择更新某一个依赖，就需要更新无数个其他依赖，因为一个 JavaScript 库大概率也是用了十几个、几十个甚至上百个其他库，而这些库又使用了更多的库……
+我不止一次听到经验丰富的前端开发者抱怨 JavaScript 的开发体验，许多工作几乎都是在更新、维护、升级依赖，以及升级依赖之后由于 API 变动，需要做的额外的适配工作。如果不做这些工作，项目可能在几个月之内就会过时，变得不可用。尽管锁定依赖版本号之后也能够继续使用旧版本，但一旦选择更新某一个依赖，就需要更新无数个其他依赖，因为一个 JavaScript 库大概率也依赖了十几个、几十个甚至上百个其他库，而这些库又使用了更多的库……
 
 由于依赖之间的层级过多，很容易造成依赖地狱（dependency hell）问题。举一个简单的例子，假设你的项目使用了软件包 A 和软件包 B，而它们同时依赖软件包 C。某一天，软件包 C 发布了新的版本，A 及时跟进了，也发布了新版本，但 B 的开发者还没有反应过来。这时，如果你更新 A，就不得不更新 C，然而 B 依赖的是旧版本的 C，不兼容新版本——A 和 B 的依赖不能被同时满足。这还只是比较简单的例子，现实中的依赖关系可能更加复杂。