跳到主要内容
Node has a config hell problem.

Node.js 的配置地狱问题

当使用 Node.js 构建时，配置通常会妨碍开发人员的生产力。但 Deno 的零配置、自带电池的理念意味着你可以立即开始高效工作。

当你启动任何风格的 Node 仓库时，你的根目录会很快充满配置文件。例如，在最新版本的 Next.js 中，你会得到 next.config.js、eslintrc.json、tsconfig.json 和 package.json。

添加样式，你也会有 postcss.config.js 和 tailwind.config.js。

需要中间件？添加 middleware.ts。想要错误监控？添加 sentry.server.config.js、sentry.client.config.js 和 sentry.edge.config.js。 此外，还有你的 env 文件、Git 文件和 Docker 文件……

在你意识到之前，你的仓库可能看起来像

30 config files in your root

所有软件都需要配置。 你需要某种方式来设置你正在使用的项目、工具、插件和软件。但是我们是如何走到需要 30 个文件才能运行一个项目的地步的？我们是如何发现自己身处配置地狱的？

我们又该如何摆脱它呢？

配置，但带有智能默认值

软件并非一刀切——所有用户都有稍微不同的需求。配置为用户提供了灵活性，使其能够根据自己的用例获得最大价值。

但是，作为使用软件的第一步 的配置是一种糟糕的用户体验。

以向现有 Next.js 项目添加 TypeScript 为例。首先，我们需要安装 TypeScript 和类型定义

npm install --save-dev typescript @types/react @types/node

然后我们需要创建我们自己的 tsconfig.json

touch tsconfig.json

然后呢？如果你刚开始使用 TypeScript，你不知道你想要什么配置，所以你会做任何有自尊心的开发人员都会做的事情：从 Stack Overflow 上窃取一个配置

{
  "compilerOptions": {
    "target": "es5",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true
  },
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx"],
  "exclude": ["node_modules"]
}

厌倦了手动向你的项目添加 TypeScript 支持？试试 Deno，其中原生支持 TypeScript。

而这仅仅是添加 TypeScript。

有效的软件通过采用智能默认值来预测用户想要完成的任务。这些“预设设置”旨在为大多数用户提供优化的体验，而无需手动配置。这些设置仍然可用，但只有在绝对必要时才会公开。

要求用户在可以使用软件之前对其进行配置可能会损害用户对你的品牌的好感和信任。想象一下，你第一次使用 Gmail，却看到这个

Gmail endless config options in its settings

你可能会突然对你旧的 Hotmail 帐户感到满意。

智能默认值优先；配置稍后。

所有这些配置文件都是什么？

让我们回到上面的列表。所有这些文件都在设置什么？

  • 忽略文件 (dockerignore, eslintignore, gitignore, prettierignore, styleignore)：它们被工具用来从操作中排除某些文件和目录。它们有助于维护清洁的环境和高效的流程。
  • 运行命令文件 (eslintrc.json, lintstagedrc.json, nvmrc, nycrc, stylelintrc.json, prettierrc.json, swcrc)：运行命令 (rc) 配置文件在运行某些命令（例如 eslint、lint-staged 等）时指定设置或参数。
  • 包文件 (package.json, yarn.lock)：这些文件提供关于依赖项和自动化脚本的重要信息，从而可以一致地管理项目的环境。
  • Next.js 文件 (middleware.ts, next-env.d.ts, Next.config.js, tsconfig.json)：这些文件管理 Next.js 应用程序的设置和配置。
  • Docker (Dockerfile, Dockerfile.deploy, docker-compose.yml)：这些文件管理用于自动化容器内部署和扩展应用程序的配置。
  • 其他 (editorconfig, happo.js, babel.config.js, playwright.config.ts, sentry.client.config.js, sentry.server.config.js, sentry.properties)：这些文件是配置文件，用于自定义和管理开发环境的各个方面，以及第三方工具和库。

Next.js。Docker。Sentry。Happo。ESLint。npm。Yarn。Playwright。Babel。VSCode。SWC。Stylelint。Prettier。NVM。NYC。lint-staged。Git。

这些工具绝非深奥难懂。它们是你将 Next.js 应用程序部署到生产环境所需的一组常用工具。而要做到这一点，你需要大约 30 个配置文件。

为什么？

JavaScript 生态系统（很大程度上）是无主见的

尽管今天的 Node.js 主要用于构建网站和应用程序，但它最初的意图相对简单：使用事件驱动的架构来实现异步 I/O。随着 Node 的普及，JavaScript 突然被用于所有方面：与浏览器/DOM 交互、文件系统和 Unix、构建系统、捆绑、转译等等。

JavaScript 的广泛实用性反映在 npm 注册表上超过 200 万个模块中。为了有用，JavaScript 模块必须支持越来越多的框架、元框架、构建工具等，以便能够插入到任何项目、任何工作流程、任何情况中。最直接的方法是保持模块“无主见”，使用广泛的配置文件来暴露与任何框架、工具或技术栈一起工作所需的复杂性。

随着更多工具被添加到 Node.js 项目中，配置文件不仅退化为累赘，而且还阻碍了开发人员的生产力。

化繁为简

软件是达到目的的手段。有效的软件不会妨碍用户，并让他们快速完成任务。

Node.js 最初是作为异步 I/O、事件驱动的 JavaScript 运行时构建的，但它并没有预料到它将在 Web 开发革命中发挥重要作用（每三个新的网页或应用程序中就有一个涉及到 Node）。但是，当开发人员使用 Node 构建新东西时，他们通常会花费大量时间将他们喜欢的技术栈和工作流程组合在一起——设置 TypeScript、他们喜欢的测试框架、他们喜欢的构建流程等等。

但是，如果我们正在为 Web 构建，并且可以立即开始高效工作，那会怎么样呢？

这就是我们构建 Deno 的方法，Deno 是一个 Web 原生运行时，具有零配置和智能默认值，因此你可以启动你的下一个项目并立即开始高效工作。它带有 原生 TypeScript 支持，因此你无需花费时间进行设置。Deno 附带 强大的工具链，内置 格式化、linting、测试 等功能，因此你无需自行设置。最后，Deno 使用 Web 兼容的 API，因此如果你已经在为 Web 构建，那么你已经熟悉 Deno。

编程是关于管理复杂性的，而让复杂的事情变得简单就是不需要配置步骤。

🍋 你知道吗？Fresh 更 Fresh 了。

务必查看 Fresh 1.3 的发布说明，Fresh 1.3 是下一代 Deno Web 框架的最新迭代版本。