babel-plugin-transform-modules-amd's Introduction

babel-plugin-transform-modules-amd

es2015 module tranformer for amd.

Difference

because of the difference between es2015 module and amd module， this plugin don't support named export and default export at the same time.

import * as foo from 'foo' and import foo from 'foo' are equal
export foo; export default foo; will throw: 'amd module don't support export default foo and , export foo both, please choose one

Installation

$ npm install babel-plugin-transform-modules-amd --save-dev

Usage

Via `.babelrc` (Recommended)

.babelrc

{
  "plugins": ["transform-modules-amd"]
}

Via CLI

$ babel --plugins transform-modules-amd script.js

Via Node API

require("babel-core").transform("code", {
  plugins: ["transform-modules-amd"]
});

babel-plugin-transform-modules-amd's People

Stargazers

Watchers

babel-plugin-transform-modules-amd's Issues

这个库的作用是啥

和babel-plugin-transform-modules-amd的区别有哪些，我们应该在什么场景下使用？

babel-plugin-transform-modules-amd add extra define when used on AMD module

When I use babel-plugin-transform-modules-amd on a module that is already in AMD format, it adds another level of define(...) around it.
Is it possible to recognize this and just leave the existing AMD module as is?

TypeError thrown when both default & named exports defined

At Luciad, we are currently in the process of converting an AMD library to ES6, but we need to maintain backwards compatibility for all of our older customers who still use AMD, by converting our ES6 modules back to AMD and shipping it in our release, along with our ES6 version.

At the moment I'm using jonbretman's amd-to-es6 to convert from AMD to ES6. This will be a one time conversion. All exports will be default exports.

I'm using your plugin to convert back to AMD. This conversion will occur at every code change until we can officially drop AMD support. Default exports should be converted & named exports should be ignored.

For most part, this two-way conversion seems to work as expected. However, your plugin supports either only default or only named exports, and it throws a TypeError if I try to add a named export next to the default export. This means that we won't be able to use it when we start adding named exports to our library in the future.

I have tried the official babel plugin as well. That one supports both default or named exports, but it does to by returning the default as a named export, named "default". This does not work for my use case.

Your plugin would be suitable for use case in the future as well, if instead of raising a TypeError it would just ignore the named exports. Is there a way this behavior could be changed?

Recommend Projects