I'd be very grateful if you could expose your internal transformation logic to use it in @babel/plugin-proposal-dynamic-import, which will then be used in @babel/preset-env. (I will mention in the docs that, when targeting commonjs, it internally uses this plugin).

Currently I'm working it around by doing this, but it is unnecessarily too hacky: link

  const transformImportCall = Function.call.bind(
    babelPluginDynamicImportNode(api).visitor.Import,
  );

Commit message:

While working on babel/babel#9552, I realized I needed two functions:

• createDynamicImportTransform is basically all what this plugin
  does, but it can be invoked directly.
• getImportSource is needed to re-use the same import argument
  stringifying logic for the AMD and SystemJS transforms

I added those functions as named exports of the main entry point,
but I had some compatibility problems because the "add-module-exports"
babel plugin automatically disables itself when there is a named
export. I resolved it by removing that plugin and manually writing
module.exports in the source file.
I couldn't disable the modules transform in the "airbnb" preset because
"transform-replace-object-assign" (v0.2.x) always injects import
declarations, even if "sourceType" is "script".

If you prefer not to have module.exports in the source file, I could create two separate entry points: babel-plugin-dynamic-import-node and babel-plugin-dynamic-import-node/utils, and export those new functions from the second one. I think that the current implementation is nicer.

NOTE: This isn't blocking the Babel release, since the workaround is working for now. I can't use getImportSource for AMD yet, but it is a minor problem.