如何使用SystemJS加载命名的导出 [英] How to load named exports with SystemJS

问题描述

如果我有一个音乐库，请说utils.js像这样

If I have a lib, say utils.js which looks like this

exports.foo = function () {
    return 'foo';
};

exports.bar = function () {
    return 'bar';
};

可用于以下用途

import {foo} from './libs/utils';

console.log(foo());

不是很壮观，但是我觉得这个问题是 SystemJS 结合使用.我必须更改代码以对其进行修复

Not very spectacular, but I get the feeling that this problem is the origin of the issue described in this post. Anyway I cannot get this to work in combination with SystemJS. I have to change the code to fix it

import utils from './libs/utils';

console.log(utils.foo());

这是我的systemjs-config文件:

Here is my systemjs-config file:

SystemJS.config({
    map: {
        'plugin-babel': 'node_modules/systemjs-plugin-babel/plugin-babel.js',
        'systemjs-babel-build': 'node_modules/systemjs-plugin-babel/systemjs-babel-browser.js',
    },
    packages: {
        '.': {
            defaultJSExtensions: 'js'
        }
    },
    transpiler: 'plugin-babel'
});

因此，似乎只能加载exports对象，而不能加载命名的导出.可以以某种方式解决此问题吗?

So, it seems only the exports object can be loaded and not the named export. Can this somehow be fixed?

更新我得到的印象是可以使用

UPDATE I get the impression it could be fixed with formats

    meta: {
    './libs/utils.js': {
        format: 'cjs'
    }
}

但是到目前为止，它仍然存在相同的问题

But so far it gives the same problems

推荐答案

此行为不是SystemJS特有的.从0.20版本开始，SystemJS就具有这种行为，因为这是ES6模块互操作性的标准化标准.

This behavior is not SystemJS specific. SystemJS behaves like this since version 0.20 because this is what ES6 module interoperability is being standardized to.

如您所问的那样，当您使用ES6 import导入CommonJS模块(通过module.exports导出)时，您将仅获得全部导出，并且无法立即对导出的名称进行破坏.

When, as in your question, you are importing CommonJS modules (exported via module.exports) using ES6 import, you will only get the entire export, and you cannot immediately destructure the exported names.

但是，当import正在通过ES6 export导出的模块时，您将能够解构导出的名称.

However, when you are importing modules which are exported via ES6 export, you will be able to destructure the exported names.

所以，这都是设计使然.盖·贝德福德(Guy Bedford)在他的博客上写了此内容，并引用了NodeJS正在进行的模块标准化:

So, it's all by design. Guy Bedford wrote about this on his blog and referenced the module standardization that is going on for NodeJS:

...导入名称时将不再允许命名导出 ES模块中的CommonJS模块，在上进行了讨论 https://github.com/nodejs/CTC/pull/60/文件#diff-2b572743d67d8a47685ae4bcb9bec651R217 .

... named exports will no longer be permitted when importing a CommonJS module from an ES module, and is discussed at https://github.com/nodejs/CTC/pull/60/files#diff-2b572743d67d8a47685ae4bcb9bec651R217.

即import { name } from 'cjs.js'，其中cjs.js是CommonJS 不再支持该模块，而是需要 import cjs from 'cjs.js'; cjs.name.

That is, import { name } from 'cjs.js', where cjs.js is a CommonJS module will no longer be supported, and instead will require import cjs from 'cjs.js'; cjs.name.

使用__esModule的互操作解决方法:

An interop workaround by using __esModule:

尽管我们将继续在互操作中支持__esModule标志， 允许取消这些情况下的指定出口.

We will continue to support the __esModule flag in interop though, allowing lifting of named exports for these cases.

因此，如果编写了cjs.js模块:

So if the cjs.js module was written:

exports.__esModule = true;
exports.name = function () {  ... }

那么即使有import { name } from 'cjs.js'; 尽管cjs.js是CommonJS模块，但是此__esModule将 最终从长远来看也会被弃用.

then it would be possible to have import { name } from 'cjs.js';, even though cjs.js is a CommonJS module, although this __esModule will eventually in the longer term be deprecated as well.

这篇关于如何使用SystemJS加载命名的导出的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！