Error: No substitution given for "_". If this is not meant to be a
                placeholder you may want to consider passing one of the following options to @babel/template:
                - { placeholderPattern: false, placeholderWhitelist: new Set(['_'])}
                - { placeholderPattern: /^_$/ }

      at metadata.placeholders.forEach.placeholder (node_modules/@babel/template/lib/populate.js:21:15)
          at Array.forEach (<anonymous>)
      at populatePlaceholders (node_modules/@babel/template/lib/populate.js:18:27)
      at arg (node_modules/@babel/template/lib/string.js:22:51)
      at arg (node_modules/@babel/template/lib/builder.js:77:14)
      at node_modules/babel-plugin-dynamic-import-node/lib/utils.js:36:89
      at PluginPass.CallExpression (node_modules/@babel/plugin-transform-modules-commonjs/lib/index.js:121:9)
      at newFn (node_modules/@babel/traverse/lib/visitors.js:179:21)
      at NodePath._call (node_modules/@babel/traverse/lib/path/context.js:55:20)
      at NodePath.call (node_modules/@babel/traverse/lib/path/context.js:42:17)
          =============
      at createDynamicImportTransform (node_modules/babel-plugin-dynamic-import-node/lib/utils.js:30:21)
      at _default (node_modules/@babel/plugin-transform-modules-commonjs/lib/index.js:22:71)
      at node_modules/@babel/helper-plugin-utils/lib/index.js:19:12
      at node_modules/@babel/core/lib/config/full.js:199:14
      at Function.<anonymous> (node_modules/@babel/core/lib/gensync-utils/async.js:26:3)
      at evaluateSync (node_modules/gensync/index.js:244:28)

Rolling back and locking into 2.3.0 resolves the issue.

I don’t know if React Native is an intended target, but hitherto it has worked extremely well. Unfortunately, with 1.1.0, it breaks, as (somehow) we end up with an extra level of functions, with error messages like

Unknown named module: 'function () {
return require(1021 ); // 1021 = @client/session
}'

IOW it seems that (at least when building with the RN packager) we end up getting a function returning the module instead of getting the module itself.

node_modules/babel-core/lib/transformation/file/options/option-manager.js:180
          throw new ReferenceError(messages.get("pluginUnknown", plugin, loc, i, dirname));
          ^

ReferenceError: Unknown plugin "dynamic-import-node" specified in "base" at 1, attempted to resolve relative to "/Users/z/project/src/containers"
    at /Users/z/project/src/_server/node_modules/babel-core/lib/transformation/file/options/option-manager.js:180:17
    at Array.map (<anonymous>)
    at Function.normalisePlugins (/Users/z/project/src/_server/node_modules/babel-core/lib/transformation/file/options/option-manager.js:158:20)
    at OptionManager.mergeOptions (/Users/z/project/src/_server/node_modules/babel-core/lib/transformation/file/options/option-manager.js:234:36)
    at OptionManager.init (/Users/z/project/src/_server/node_modules/babel-core/lib/transformation/file/options/option-manager.js:368:12)
    at compile (/Users/z/project/src/_server/node_modules/babel-register/lib/node.js:103:45)
    at loader (/Users/z/project/src/_server/node_modules/babel-register/lib/node.js:144:14)
    at Object.require.extensions.(anonymous function) [as .js] (/Users/z/project/src/_server/node_modules/babel-register/lib/node.js:154:7)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)

require('babel-register')({ plugins: ["transform-decorators-legacy", "dynamic-import-node"], presets: ['es2015', 'stage-0', 'react'], // ignore: /scss/, extensions: [".es6", ".es", ".jsx", ".js"] });
trying to use this plugin cause i got SyntaxError: Unexpected token import on server side rendering
when trying to use webpack dynamic import in my react components

The devDependency eslint-plugin-import was updated from 2.16.0 to 2.17.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

eslint-plugin-import is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Reproduction

var babelPluginDynamicImportNode = require("babel-plugin-dynamic-import-node");
var babel = require("@babel/core");

var input = `
let i = 0;
import("./file-" + i++ + ".js");
assert(i === 1);

async function fn() {
  await import(await getSource());
}
`

var out = babel.transformSync(input, {
  configFile: false,
  plugins: [babelPluginDynamicImportNode]
});

console.log(out.code);

Output

let i = 0;
Promise.resolve().then(() => _interopRequireWildcard(require(`${"./file-" + i++ + ".js"}`)));
assert(i === 1);

async function fn() {
  await Promise.resolve().then(() => _interopRequireWildcard(require(`${await getSource()}`)));
}

As you can see in the output code, the first assertion fails because i++ is evaluated asynchronously, and the second one is a syntax error because await is inside a non-arrow function.

Proposed output

We can pass the import argument in Promise.resolve, so that it is in the correct scope:

let i = 0;
Promise.resolve(`${"./file-" + i++ + ".js"}`).then(_ => _interopRequireWildcard(require(_)));
assert(i === 1);

async function fn() {
  await Promise.resolve(`${await getSource()}`).then(_ => _interopRequireWildcard(require(_)));
}

Could you please clarify one thing. When I use babel-node with this plugin, all is okay. But if I use this plugin during babel compilation like this:

"build": "babel lib -d dist --presets es2015,stage-2"

will babel-plugin-dynamic-import-node work after compilation? I mean if for example I use dynamic import like this:

myLib.js:
import express from 'express';

index.js:

const dynamicModuleName = './my';
import(dynamicModuleName + 'Lib.js');

and compilation command:

"build": "babel index.js -d dist --presets es2015,stage-2"

Will babel-plugin-dynamic-import-node plugin compile myLib.js file during compilation or not?

i need chunk file for dynamic loader and server render

Version 6.22.0 of babel-types just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As babel-types is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Im deploying an application to heroku that uses your plugin, and im getting the following error on execution after successful build :

ReferenceError: Unknown plugin "dynamic-import-node" specified in "/app/package.json" at 0, attempted to resolve relative to "/app"

Plugins for babel are setup like this:

"plugins": [
  "loadable-components/babel",
  "dynamic-import-node",
  "lodash"
],

In my local machine the build process works flawlessly but in heroku fails.

Thanks for any kind of help you can provide.

Babel 7.10 is going to support parsing stage-1 module attributes

await import("./package.json", { with: { type: "json" } })

Currently this plugin will transform the code above to

await Promise.resolve().then(() => _interopRequireWildcard(require("./package.json")));

where module attributes are excluded.

Given that node require supports JSON, I think the current situation is still acceptable, but only if type: "json" is the only accepted in the proposal. That said, if the spec will allow other type values in the future, we should decide

Should we skip the import node with module attributes? Since we can offer a custom plugin to transform module attributes into bundler-specific annotations, e.g. import(/* webpackChunkName: "lodash" */ 'lodash')

Or should we still treat them as those without attributes? A warning message can be printed since it may not be natively supported on node.js, but users may intend to pass the transpiled sources through bundlers which may support them via file extensions.

I don't have preference between these two solutions, or maybe we should even pursuit for an option. Other solutions are definitely welcome.

What's the difference between babel-plugin-syntax-dynamic-import vs babel-plugin-dynamic-import-node?
I tried babel-plugin-syntax-dynamic-import and it works fine for my Webpack v4 setup.
Why would I consider babel-plugin-dynamic-import-node instead?

Node can no longer find my dynamic imports from version 2.3.3.

I compared the generated bundles and found this diff:
Before:

await Promise.resolve().then(() => __webpack_require__("./src/api sync recursive ^\\.\\/.*$")(`./${functionName}`));

After:

await Promise.resolve(`api/${functionName}`).then(s => __webpack_require__("./src sync recursive")(s));

This is the error produced:

Error: Cannot find module 'api/pdf'
    at webpackEmptyContext (/Users/richard/Projects/riktiga-vykort/.webpack/service/src/webpack:/src sync:2:1)

This is my source:

  const functionName = process.env.FUNCTION_NAME

  await import(
    `api/${functionName}`
  )

This is index.js of babel-plugin-dynamic-import-node which I downloaded from npm, also v.1.0.2

Object.defineProperty(exports, "__esModule", {
  value: true
});

var _babelTemplate = require('babel-template');

var _babelTemplate2 = _interopRequireDefault(_babelTemplate);

var _babelPluginSyntaxDynamicImport = require('babel-plugin-syntax-dynamic-import');

var _babelPluginSyntaxDynamicImport2 = _interopRequireDefault(_babelPluginSyntaxDynamicImport);

var _babelTypes = require('babel-types');

var t = _interopRequireWildcard(_babelTypes);

function _interopRequireWildcard(obj) { if (obj && obj.__esModule) { return obj; } else { var newObj = {}; if (obj != null) { for (var key in obj) { if (Object.prototype.hasOwnProperty.call(obj, key)) newObj[key] = obj[key]; } } newObj['default'] = obj; return newObj; } }

function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { 'default': obj }; }

var TYPE_IMPORT = 'Import';

var buildImport = (0, _babelTemplate2['default'])('\n  Promise.resolve().then(() => require(SOURCE))\n');

exports['default'] = function () {
  return {
    inherits: _babelPluginSyntaxDynamicImport2['default'],

    visitor: {
      CallExpression: function () {
        function CallExpression(path) {
          if (path.node.callee.type === TYPE_IMPORT) {
            var importArgument = path.node.arguments[0];
            var newImport = buildImport({
              SOURCE: t.isStringLiteral(importArgument) || t.isTemplateLiteral(importArgument) ? path.node.arguments : t.templateLiteral([t.templateElement({ raw: '', cooked: '' }), t.templateElement({ raw: '', cooked: '' }, true)], path.node.arguments)
            });
            path.replaceWith(newImport);
          }
        }

        return CallExpression;
      }()
    }
  };
};

Why is it completely different than index.js here, in this repo?

Btw. the one on GitHub doesn't seem to work (still returns unexpected token), the one on npm works, but only after you add module.exports = exports["default"] at the end of index.js, otherwise babel-jest returns Plugin 1 specified in "base" provided an invalid property of "default"

This is blocking a complete update to Babel 7 in my react app.
It is a dependency of babel-plugin-react-app, which uses babel 7

Heya! I'm seeing that there are two packages, pointing to this repo, but one is v1.2.0 and the another one is v2.0.0. So which one to use and which is most recent and okey for future?

• babel-plugin-dynamic-import-node
• babel-plugin-transform-dynamic-import

Version 6.22.0 of babel-core just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As babel-core is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Hi there! This Babel plugin seems particularly useful, but we have got a question about the usage:

Is there anything to take care of when transpiling for both webpack and node as targets or is there a suggested best practice? The readme doesn't mention this use case.

So when using dynamic imports with Webpack v4, Webpack is now using a namespace object.

https://github.com/webpack/webpack/releases/tag/v4.0.0
https://medium.com/webpack/webpack-4-import-and-commonjs-d619d626b655

This matches what is done when you use ESM modules and you import Commonjs. You have to reference "default" now in Webpack v4 when attempting to reference module.exports. This is not the same as doing a deferred require on the server. My workaround has been to do something akin to this

const EXIFModule = await import(/* webpackChunkName: "exif-js" */ 'exif-js');
// Gets around dynamic import inconsistencies between browser and server
const EXIF = EXIFModule.default || EXIFModule;

Ideally, there would be some way to at least have a setting for this plugin to turn on namespace object dynamic imports.

Matches the proposed spec.

are query params and fragments part of the spec?

repro:

await import('./index.js#test')
// throws: Cannot find module './index.js#test'

await import('./index.js?test=test')
// throws: Cannot find module './index.js?test=test'

in addition, this makes it impossible to force reimporting a module and get a fresh module record, e.g. for loading modules in tests.

While working on microsoft/TypeScript#49663, Ron Buckton pointed out a pitfall in my initial implementation, which was largely inspired by this plugin. Example:

const a = import(Promise.resolve("foo"));

This should be importing [object Object], instead of foo.

Alternative solution is proposed in microsoft/TypeScript#49663 (comment)

I just wanted to check what's new happened since current version I have (1.2.0), but I see nothing in releases.

😟

Adding babel-preset-es2015 along with babel-plugin-dynamic-import-node causes a bad interaction between the two that causes a failure in the compilation.

I think this may also have something to do with what the reporter is seeing in #13.

Here's the full stacktrace:

TypeError: unknown: Property value expected type of string but got null
      at Object.validate (node_modules/babel-types/lib/definitions/index.js:161:13)
      at validate (node_modules/babel-types/lib/index.js:505:9)
      at Object.builder (node_modules/babel-types/lib/index.js:466:7)
      at PluginPass.TemplateLiteral (node_modules/babel-plugin-transform-es2015-template-literals/lib/index.js:81:24)
      at newFn (node_modules/babel-traverse/lib/visitors.js:276:21)
      at NodePath._call (node_modules/babel-traverse/lib/path/context.js:76:18)
      at NodePath.call (node_modules/babel-traverse/lib/path/context.js:48:17)
      at NodePath.visit (node_modules/babel-traverse/lib/path/context.js:105:12)
      at TraversalContext.visitQueue (node_modules/babel-traverse/lib/context.js:150:16)
      at TraversalContext.visitMultiple (node_modules/babel-traverse/lib/context.js:103:17)
      at TraversalContext.visit (node_modules/babel-traverse/lib/context.js:190:19)
      at Function.traverse.node (node_modules/babel-traverse/lib/index.js:114:17)
      at NodePath.visit (node_modules/babel-traverse/lib/path/context.js:115:19)
      at TraversalContext.visitQueue (node_modules/babel-traverse/lib/context.js:150:16)
      at TraversalContext.visitSingle (node_modules/babel-traverse/lib/context.js:108:19)
      at TraversalContext.visit (node_modules/babel-traverse/lib/context.js:192:19)
      at Function.traverse.node (node_modules/babel-traverse/lib/index.js:114:17)
      at NodePath.visit (node_modules/babel-traverse/lib/path/context.js:115:19)
      at TraversalContext.visitQueue (node_modules/babel-traverse/lib/context.js:150:16)
      at TraversalContext.visitMultiple (node_modules/babel-traverse/lib/context.js:103:17)
      at TraversalContext.visit (node_modules/babel-traverse/lib/context.js:190:19)
      at Function.traverse.node (node_modules/babel-traverse/lib/index.js:114:17)
      at NodePath.visit (node_modules/babel-traverse/lib/path/context.js:115:19)
      at TraversalContext.visitQueue (node_modules/babel-traverse/lib/context.js:150:16)
      at TraversalContext.visitSingle (node_modules/babel-traverse/lib/context.js:108:19)
      at TraversalContext.visit (node_modules/babel-traverse/lib/context.js:192:19)
      at Function.traverse.node (node_modules/babel-traverse/lib/index.js:114:17)
      at NodePath.visit (node_modules/babel-traverse/lib/path/context.js:115:19)
      at TraversalContext.visitQueue (node_modules/babel-traverse/lib/context.js:150:16)
      at TraversalContext.visitMultiple (node_modules/babel-traverse/lib/context.js:103:17)
      at TraversalContext.visit (node_modules/babel-traverse/lib/context.js:190:19)
      at Function.traverse.node (node_modules/babel-traverse/lib/index.js:114:17)
      at NodePath.visit (node_modules/babel-traverse/lib/path/context.js:115:19)
      at TraversalContext.visitQueue (node_modules/babel-traverse/lib/context.js:150:16)
      at TraversalContext.visitQueue (node_modules/babel-traverse/lib/context.js:156:21)
      at TraversalContext.visitSingle (node_modules/babel-traverse/lib/context.js:108:19)
      at TraversalContext.visit (node_modules/babel-traverse/lib/context.js:192:19)
      at Function.traverse.node (node_modules/babel-traverse/lib/index.js:114:17)
      at NodePath.visit (node_modules/babel-traverse/lib/path/context.js:115:19)
      at TraversalContext.visitQueue (node_modules/babel-traverse/lib/context.js:150:16)
      at TraversalContext.visitMultiple (node_modules/babel-traverse/lib/context.js:103:17)
      at TraversalContext.visit (node_modules/babel-traverse/lib/context.js:190:19)
      at Function.traverse.node (node_modules/babel-traverse/lib/index.js:114:17)
      at NodePath.visit (node_modules/babel-traverse/lib/path/context.js:115:19)
      at TraversalContext.visitQueue (node_modules/babel-traverse/lib/context.js:150:16)
      at TraversalContext.visitSingle (node_modules/babel-traverse/lib/context.js:108:19)
      at TraversalContext.visit (node_modules/babel-traverse/lib/context.js:192:19)
      at Function.traverse.node (node_modules/babel-traverse/lib/index.js:114:17)
      at traverse (node_modules/babel-traverse/lib/index.js:79:12)
      at File.transform (node_modules/babel-core/lib/transformation/file/index.js:548:35)
      at node_modules/babel-core/lib/transformation/pipeline.js:50:19
      at File.wrap (node_modules/babel-core/lib/transformation/file/index.js:564:16)
      at Pipeline.transform (node_modules/babel-core/lib/transformation/pipeline.js:47:17)
      at testPlugin (test/testPlugin.js:4:18)
      at Context.<anonymous> (test/index.js:18:22)

Version 2.4.0 of eslint-plugin-import just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As eslint-plugin-import is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Webpack introduced recently a non-standard feature to customize the import() function

https://webpack.js.org/api/module-methods/#import-

Unfortunately using these comments breaks the plugin and the import() doesn't get transpilled correctly.

.babelrc

{ "plugins": ["dynamic-import-node"] }

index.js, broken syntax

import(/* webpackChunkName: "Foo.Module" */ './foo.js');

index.js, correct syntax

import('./foo.js');

When I add this plugin when code splitting with import('./ModuleA') doesn't work(((
But If I change import code to System.import all work perfectly.
You known how I can fix it?

@babel/plugin-syntax-dynamic-import

Are there plans to use the package on the newer babel namespace?

Version 2.3.0 of babel-preset-airbnb just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As babel-preset-airbnb is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 4.11.0 of eslint was just published.

This version is covered by your current version range and after updating it in your project the build failed.

eslint is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

For me the main use case for this plugin is to allow bundling of my React app with Webpack while still supporting server side rendering. In a Node environment I actually want the code to be required at startup so the initial SSR isn't delayed while the bundle is evaluated.

If this is something you're interested in supporting I could make a PR, it should be as simple as using a template like Promise.resolve(require(SOURCE)) when some option is set.

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Added the new Node.js version to your .travis.yml

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

Your Greenkeeper Bot 🌴

Hi I was experimenting with some stuff in create-react-app 2.0 and noticed that this project's code seems to be out of sync with what has been published in npm.

Current package.json

package.json of node_modules/babel-plugin-transform-dynamic-import after npm i in new project:

  "devDependencies": {
    "@babel/cli": "7.0.0-beta.34",
    "@babel/core": "7.0.0-beta.34",
    "@babel/plugin-transform-template-literals": "^7.0.0-beta.34",
    "@babel/preset-env": "^7.0.0-beta.34",
    "@babel/preset-es2015": "^7.0.0-beta.34",
    "@babel/register": "7.0.0-beta.34",
    "airbnb-js-shims": "^1.3.0",
    "babel-eslint": "^8.0.3",
    "chai": "^4.1.2",
    "eslint": "^4.11.0",
    "eslint-config-airbnb-base": "^12.1.0",
    "eslint-plugin-import": "^2.8.0",
    "in-publish": "^2.0.0",
    "mocha": "^4.0.1",
    "rimraf": "^2.6.2",
    "safe-publish-latest": "^1.1.1"
  }

The devDependency eslint-plugin-import was updated from 2.18.2 to 2.19.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

eslint-plugin-import is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

I'm trying to do a small PR but i can't seem to figure out what npm run check-changelog wants me to do 😢

This repo is at 2.1.0, while the npm package (babel-plugin-transform-dynamic-import
) is at 2.0.0. And it uses a beta version of Babel 7, while this repo is still at Babel 6.
Please update both the repo and the npm package please

in vue-router

  {
    path: '/',
    name: 'home',
    component: () => import('@/views/home/index'),
    meta: {
      title: 'Home'
    }
  }

error: Critical dependency: the request of a dependency is an expression;
webpack-internal:///./node_modules/vue-router/dist/vue-router.esm.js:17 [vue-router] Failed to resolve async component default: Error: Cannot find module '@/views/home/index'

Rolling back and locking into 2.3.0 resolves the issue.

my module file use
export default userSchema;
when use
import('path-to-module').then( module => { let m = module.default; ....})
so the m is the real module.
it's behavior is not equal to require()
can make import() use like require()?

Version 6.22.1 of babel-cli just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As babel-cli is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

hi

same this one:
millermedeiros/esformatter#478

const middleware = import(`./${path.relative(__dirname, dir)}/${item}`) .then(middlewareImport => middlewareImport.default)

at Parser.pp$5.raise (/node_modules/babel-core/node_modules/babylon/lib/index.js:4452:13)

source code
import ('./index.jsx')
build result:
Promise.resolve().then(() => _interopRequireWildcard(require('./index.jsx')));

It doesn`t work

Readme do not hint anything how to use it or may be I am dumb.