export default {name}和named export {name}之间的区别

问题描述 投票:0回答:1

我试图弃用具有许多命名导出的模块,如下所示:

const Foo = () => 'foo';
const Bar = () => 'bar';

export { Foo };
export { Bar };

通过以下方式消费时很好:

import { Foo, Bar } from './something';

我对启用弃用警告的想法是使用类型为对象的默认导出,并为每个打印弃用的键提供属性getter覆盖,然后返回模块。

然后形状变成如下:

const something = {};
Object.defineProperty(something, 'Foo', {
  get(){
    console.warn('Foo is deprecated soon');
    return Foo;
  }
});
// etc
export default something;

我的想法是,解构导入会解决这个问题

import { Foo, Bar } from './something';

......会像以前一样继续工作。相反,webpack抱怨某些东西没有命名导出Foo或Bar

然而,使用它,有效:

const { Foo, Bar } = require('./something');

我也可以使用import something from './something'; const { Foo, Bar } = something,但是如果我必须重构每个存在的导入,它就会失败。

所以问题实际上是关于import { Foo, Bar } from './something';require()相比如何工作 - 我认为如果默认导出是一个对象,它会解决它并解构,但没有快乐。

是否有一种简单的方法可以在不改变其他地方出口的情况下进行“代理”?

javascript webpack ecmascript-6
1个回答
1
投票

我想我做到了。请记住,这是一种解决方法。

鉴于您说从单个文件“重新导出”库,您可以在“重新导出”中添加一个额外的“层”,我们将“重新导出”文件转换为JS文件并编写为它自己关联的打字文件。

工作代表:https://repl.it/@Olian04/CelebratedKlutzyQuotes

代码片段:

// index.ts
// consuming the library
import { Foo } from './demo';

console.log(Foo());
// library.ts
// the library it self
const Foo = () => 'foo';

export { Foo }
// demo.js
// the workaround implementation 
const depricatedLibrary = require('./library');

const something = new Proxy(depricatedLibrary, {
  get(obj, key) {
    if (typeof key === 'string') {
      console.warn(key + ' is deprecated soon');
    }
    return obj[key];
  }
});

module.exports = something;
// demo.d.ts
// the workaround types
export * from './library';
© www.soinside.com 2019 - 2024. All rights reserved.