我们仍然需要尽一切努力为NPM预编译软件包吗？

Question

我目前正在从事一个项目，该项目将为npm提供许多软件包。我想对该项目采取更激进的方法。因此，不再需要预编译任何文件。在软件包的src文件夹中，只有d.ts，ts，js，mjs文件（如我所说，其中任何一个都不应进行预编译）。我这样做是出于懒惰，因为我认为已经准备好停止预编译文件了！

我的意思是我应该创建多少个版本？ ESModules，AMD，CommonJs，SystemJS？

我的简单想法是：保持原样（从'x'导入x，导出foo = 123），使用该软件包的开发人员将已经拥有正确的工具（Babel，Typescript）！是否？

第二个问题是：程序包应编译到哪个级别？ ES3，ES6？仅使用现代浏览器并仅支持现代浏览器的软件包用户有哪些？在这里differential loading是正确的方法吗？我只看到HTML文件环境中的差异加载。因此作为起点！如果开发人员有选择地使用软件包，对我来说不是这种情况。

具体来说，我的问题是：我们仍然需要付出所有这些努力吗？当前的最低公分母是什么？我不知道统计数字，但是我感觉每个人都在他的项目中使用编译器/预处理器（Babel，PostCss）？

您对此有何看法？

Answer 1

根据我的经验，CommonJS和ES模块是当今的相关技术。您可能决定跳过CommonJS，然后不进行转译就可以相处。但是，许多框架和其他库仍然依赖CommonJS，它们不能使用ES模块。

作为轻量级方法，您可以做的是以下事情：

First：默认情况下将所有内容都编写为ES模块，并布局您的程序包以默认用作ES模块（例如，在package.json中设置"type":"module"并使用.mjs作为文件结束）。

Then：使用Babel，但仅用于创建模块的CommonJS后备。看起来可能像这样：

将以下开发依赖项添加到您的项目中：

npm install --save-dev @babel/cli @babel/core @babel/plugin-syntax-import-meta @babel/plugin-transform-modules-commonjs

然后将以下块添加到package.json：

"babel": {
    "plugins": [
        [ "@babel/plugin-transform-modules-commonjs" ],
        [ "@babel/plugin-syntax-import-meta" ]
    ]
}

现在您可以使用简单的外壳代码将ES模块转换为CommonJS：

# assuming your ES modules are in the lib/ directory
for script in $(find lib/ -iname '*.mjs' | grep -v test.mjs | sed -e 's|.mjs||g'); do
    npx babel $script.mjs > $script.cjs
done

您还可以将其作为脚本添加到package.json。

"scripts": {
    "build": "for script in $(find lib/ -iname '*.mjs' | grep -v test.mjs | sed -e 's|.mjs||g'); do npx babel $script.mjs > $script.cjs; done"
}

现在，您可以使用npm run build运行它，将其添加为提交挂钩，或者在推送到NPM注册表之前运行它。您还可以建立与ES模块所在目录不同的文件夹，并通过.gitignore排除该文件夹。

这是我创建多个我的库的方式（出于完全相同的原因），并且在CommonJS和ES模块环境中都可以完美运行。