关于前端:体系课吃透前端工程化大厂级实战项目以战带练

45次阅读

共计 2762 个字符,预计需要花费 7 分钟才能阅读完成。

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
你感觉这个个性对将来前端工程化会有多大影响呢?

正文完
 0