Download_点击获取: 【体系课】吃透前端工程化，大厂级实战我的项目以战带练

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

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

本文参考：

Custom ESM loaders: Who, what, when, where, why, how[2]

个性简介
用过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文件举例，假如CSS文件内容如下：

.Container {
border: 1px solid black;
}

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

{
"Container": "Container",
"SomeInnerPiece": "SomeInnerPiece"
}
参考：CSS loader的繁难实现[3]

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

当辨认到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的繁难实现[4]

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

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

$> node --loader typescript-loader --loader css-loader --loader network-loader app.tsx
你感觉这个个性对将来前端工程化会有多大影响呢？