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
。另外,还有您的环境檔案、Git 文件以及 Docker 文件…
在您不知不觉中,您的代码库可能看起来像这样
所有软件都需要配置。 您需要某种方式来设置您正在使用的项目、工具、插件和软件。但是我们是如何走到需要 30 个檔案来运行一个项目的地步的?我们是如何陷入配置地狱的?
我们如何摆脱困境?
配置,但使用智能默认值
软件并非一刀切——所有用户都有略微不同的需求。配置让用户可以灵活地根据自己的用例获得最大价值。
但配置作为使用软件的第一步是一种糟糕的用户体验。
以将 TypeScript 添加到现有的 Next.js 项目为例。首先,我们需要安装 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,迎接您的却是这个
您突然会对您旧的 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 附带 强大的工具链,其中包含内置的 格式化、代码整理、测试 等功能,因此您无需自己进行设置。最后,Deno 使用 与 Web 兼容的 API,因此如果您已经为 Web 构建,您已经熟悉 Deno。
编程就是关于管理复杂性,将复杂的事情简单化就是不要求配置步骤。
🍋 您知道吗?Fresh 变得更清新了。
请务必查看 Fresh 1.3 的发行说明,这是为 Deno 推出的下一代 Web 框架的最新版本。