Say goodbye to Node.js, Deno zero-configuration solution

I don’t know if you have noticed that when we start various types of Node repo, the root directory will soon be filled with configuration files. For example, in the latest version of Next.js, we have next.config.js, eslintrc.json, tsconfig.json and package.json. On the style side, there are postcss.config.js and tailwind.config.js.

If you add the middleware middleware.ts, error monitoring sentry.server.config.js, sentry.client.config.js and entry.edge.config.js, as well as various env files, Git files and Docker files... then there are still Before we can recover, the repo may have become like this:

All software requires configuration. After all, we all have to have some way of setting up the projects, tools, plug-ins, and software we are using. But is it really necessary to run a single project with 30 files? The answer is no, so what do we need to do?

Configure, but use smart defaults

There is no “silver bullet” in software—all users’ needs will be slightly different. Configuration gives users more flexibility to extract maximum value from the software based on actual use cases. But "Want to use the software? Configure it first" is indeed a very bad user experience.

Let's take adding TypeScript to an existing Next.js project as an example to see how the entire process progresses. First, we need to install TypeScript and types:

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

Then you need to create your own tsconfig.json:

touch tsconfig.json

Next, if you have just started using TypeScript and can’t figure out what configuration you need, you must use the “secret weapon” that developers all know-get a set of configurations from 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"]
}

Don't want to manually add TypeScript support to your project? You can try Deno, which supports TypeScript natively. And this is just adding TypeScript.

Effective software can predict what users want to achieve through smarter defaults. These "preset options" provide an optimized experience for most users and require no manual configuration. Therefore, it is wise to first provide a usable configuration template and then ask users to make adjustments when necessary.

In fact, directly throwing the software configuration page in the user's face is definitely not good for the brand's reputation and damages customer trust. Imagine if we used Gmail for the first time, we would see this picture:

Then the devil wants to use your Google, you might as well stay with Hotmail. Therefore, smart default items are put first, and configuration adjustments are made when necessary.

Configuration file analysis

Let's go back to the previous configuration list. What settings are there for these files?

• Ignore files (dockerignore, eslintignore, gitignore, prettierignore, styleignore): Their function is to exclude certain files and directories from operations. They help keep the environment clean and execution processes more efficient.
• Run command files (eslintrc.json, lintstagedrc.json, nvmrc, nycrc, stylelintrc.json, prettierrc.json, swcrc): The run command (rc) configuration file is responsible for specifying the settings or parameters of certain commands at run time, such as eslint, lint-staged etc.
• Package files (package.json, yarn.lock): These files provide important information about automation dependencies and scripts, allowing for unified management of the project environment.
• Next.js files (middleware.ts, next-env.d.ts, Next.config.js, tsconfig.json): These files manage the settings and configuration of the Next.js application.
• Docker (Dockerfile, Dockerfile.deploy, docker-compose.yml): These files manage the automated deployment and scaling configuration of applications within containers.
• Others (editorconfig, happo.js, babel.config.js, playwright.config.ts, sentry.client.config.js, sentry.server.config.js, sentry.properties, ): These configuration files are responsible for customization and management Set up all aspects of the development environment, including third-party tools and libraries.

In addition, there is Next.js. Docker. Sentry. Happo. ESLint. npm. Yarn. Playwright. Babel. VSCode. SWC. Stylelint. Prettier. NVM. NYC. lint-staged. Git. In fact, these tools are not esoteric and are a general collection of tools needed to deploy Next.js applications into production.

JavaScript ecosystem

Although Node.js is mainly used to build websites and web applications today, its original design goal was actually not that strong, but more of an event-driven architecture to enable asynchronous I/O. But with the popularity of Node, JavaScript suddenly took over the high ground: interacting with the browser/DOM, file system and Unix, building systems, bundling, transpiling, etc.

JavaScript's widespread utility is demonstrated by the more than 2 million modules in the npm registry. To be useful, JavaScript modules must be able to support an increasing number of frameworks, meta-frameworks, build tools, etc., so that they can be smoothly plugged into different projects for various workflows in any situation. The most direct way is, of course, to use a wider range of configuration files to maintain the module's universal ability. Therefore, a large number of configuration files actually reflect the objective complexity of JavaScript that needs to be used with multiple frameworks, tools, and technology stacks.

As more and more tools are added to Node.js projects, configuration files not only become more cumbersome, but also reduce developer productivity.

Simplify the complex

Software is a means to achieve goals. Truly efficient software will never "disgust" users, but help them complete tasks quickly.

Node.js was originally built as an asynchronous I/O, event-driven JavaScript runtime. Its creators at the time had no idea that it would play a key role in revolutionizing web development (currently, every three new web pages or One of the web applications uses Node). However, when developers use Node to build new products, they often need to spend a lot of time integrating the technology stack and workflow they need - such as setting up TypeScript, setting up a familiar testing framework and build process, etc.

Is there a way to put our web construction results into production immediately?

This is what the Deno project is about. It is a web-native runtime with zero configuration and smart defaults, so you can immediately enjoy the efficiency improvements it brings when developing new projects. It has native TypeScript support, so no extra time is needed to set it up. Deno also comes with a powerful tool chain that provides built-in formatting, linting quality checking, testing and other functions, all out of the box. Finally, Deno also uses a web-compatible API, so if you are already building web applications, you should not have any difficulty getting started with Deno.

That's what programming is all about: managing complexity and making it simple. So, let’s join hands with Deno and say goodbye to annoying configuration steps.