关于javascript:可能改变前端工程化未来的特性ESM-Loader-Hooks

大家好，我卡颂。

在最近公布的 Node v18.6.0 中，带来了一个试验个性 ESM Loader Hooks API。

如果他最终落地，很可能会成为扭转前端工程化将来的个性。本文咱们来聊聊他。

欢送退出人类高质量前端框架群，带飞

本文参考：

Custom ESM loaders: Who, what, when, where, why, how

用过 webpack 的敌人肯定晓得 webpack 中有个 loader 的概念，用于加载并解决不同类型文件，比方css-loader、url-loader。

loader的执行程序取决于 webpack 外部对文件树解析、遍历的程序。

明天要介绍的 ESM Loader Hooks 与webpack loader相似，只不过对文件树的解析、遍历是由 Node.js 原生反对的 ESM 标准（而不是打包工具）确定的。

通过定义不同 loader，就能在 不应用工程化工具 的前提下，对我的项目中各个 ESM 模块进行解决。

举个例子，在命令行通过 --experimental-loader 指令开启个性后，执行如下语句：

$> node --loader redirect.mjs app.mjs

其中，app.mjs为 待处理的源文件 ，.mjs 后缀指代该文件是个 ESM 模块（绝对应的，.cjs后缀指 CJS 模块）。

--loader用于指定自定义的 ESM Loader，这里指定的是redirect.mjs，app.mjs 会交由 redirect.mjs 解决。

redirect.mjs代码如下：

// redirect.mjs
export function resolve(specifier, context, nextResolve) {
  let redirect = 'app.prod.mjs';

  switch(process.env.NODE_ENV) {
    case 'development':
      redirect = 'app.dev.mjs';
      break;
    case 'test':
      redirect = 'app.test.mjs';
      break;
  }

  return nextResolve(redirect);
}

redirect.mjs会依据 Node 以后所属环境 改写文件的引入门路。

比方在开发环境（process.env.NODE_ENV === 'development'），app.mjs经由 redirect.mjs 解决，会重定向到app.dev.mjs。

ESM Loader Hooks API中之所以带 Hooks 字眼，是因为每个 自定义 ESM Loader，都能够像钩子（Hooks）一样连贯其余 自定义 ESM Loader（或者 Node.js 提供的默认ESM Loader）。

比方在如下语句中：

$> node --loader c.mjs --loader b.mjs --loader a.mjs app.mjs

app.mjs会顺次通过 a b c 三个 自定义 ESM Loader解决。

整个过程就像一个 promise.then 链条（事实上，每个 ESM loader 的确会返回一个promise）。

来看一个更靠近日常开发的例子，思考如下 ESM 模块：

// app.tsx
import ReactDOM from 'react-dom/client';
import {
  BrowserRouter,
  useRoutes,
} from 'react-router-dom';

import App from './AppHeader.tsx';

import routes from 'https://example.com/routes.json' assert {type: 'json'};

import './global.css' assert {type: 'css'};

const root = ReactDOM.createRoot(document.getElementById('root'));

root.render(
  <BrowserRouter>
    <App />
    <main>{useRoutes(routes)}</main>
  </BrowserRouter>
);

其中包含很多 Node.js 不能解决的局部，比方：

TS语法（须要编译成 JS，并解决文件描述符为Node.js 可辨认的模式）
JSX转换（须要编译成 React.createElement 或jsxRuntime.jsx）
须要解决引入的 CSS 文件
须要解决近程引入的模块（代码中引入 routes 的语句）

以解决 CSS 文件举例，假如 CSS 文件内容如下：

.Container {border: 1px solid black;}

.SomeInnerPiece {background-color: blue;}

如果为了测试目标，仅须要生成类名对应快照即可，所以能够实现一个繁难的 CSS loader，解决输出的CSS 文件，将后果输入为 Node.js 可执行的 JSON 格局：

{ 
  "Container": "Container", 
  "SomeInnerPiece": "SomeInnerPiece"
}

参考：CSS loader 的繁难实现

再以解决 解决近程引入的模块 举例。

当辨认到 https:// 结尾的文件描述符（即 import 申明或 import() 表达式中字符串的局部）时，能够利用 https 模块发动申请，返回申请对应promise：

import {get} from 'https';

export function load(url, context, nextLoad) {if (url.startsWith('https://')) {return new Promise((resolve, reject) => {get(url, (res) => {
        let data = '';
        res.on('data', chunk => data += chunk);
        res.on('end', () => resolve({
          format: 'module',
          shortCircuit: true,
          source: data,
        }));
      }).on('error', err => reject(err));
    });
  }

  return nextLoad(url, context);
}

参考：Https loader 的繁难实现

当 ESM Loader Hooks 个性趋于稳定，配套的 loader 生态足够丰盛后，很多原来须要打包工具能力实现的工程化需要都能用 Node.js 原生解决。

比方，要解决上述提到的 app.tsx 文件，只需执行如下命令：

$> node --loader typescript-loader --loader css-loader --loader network-loader app.tsx

你感觉这个个性对将来前端工程化会有多大影响呢？

关于javascript:可能改变前端工程化未来的特性ESM-Loader-Hooks

个性简介

理论例子

解决 CSS 文件

解决近程引入的模块

总结