Support more cases where modules are being required in a dynamic way

[fabiospampinato]

Feature request

What is the expected behavior?

Sometimes modules are imported in a more dynamic way than WebPack currently supports, for instance there are multiple packages for lazily importing modules, so one might write code like this:

const importLazy = require ( 'import-lazy' );
const lodash = importLazy ( 'lodash' );

And WebPack will not include lodash in the bundle, but it should.

What is motivation or use case for adding/changing the behavior?

Some modules I depend on import modules like that, perhaps even in more dynamic ways. It's not always possible to make those packages WebPack-compatible (just import-lazy alone has ~4M+ weekly downloads, we can't update all the packages depending on it), but WebPack should still be smart enough to bundle our code correctly.

How should this be implemented in your opinion?

Solving this without requiring any modification at all to existing packages might be impossible, as I think WebPack would have to start executing the code it's trying to bundle in a very smart way.

But perhaps there could be a way for modules like import-lazy to tell WebPack: "This function may require the following modules when such and such happen", maybe some magic comment like:

function importLazy ( originalRequire ) { /* webpack-interface: () => require */
  return function lazyRequirer ( pkg ) {
    return originalRequire ( pkg );
  };
}

Could instruct webpack to treat it as if it was the provided code or something? And then WebPack could figure out that if foo and bar modules are being passed through that code they are eventually going to get required, so it can include those modules in the bundle too.

Are you willing to work on this yourself?

I'm not sure I'd be able to implement this, but maybe I could try 🤷‍♂

[sokra]

We can't have special handling for all these not statically analyse-able code. This is out of scope for webpack. import-lazy is only used by 33 modules.

If would be easy to create a lazy importing API with a statically analyse-able API:

const importLazy2 = require("import-lazy");
const lodash = importLazy2(() => require("lodash"));

Maybe this is something @sindresorhus can consider for import-lazy...

---

Somebody promoted laxy which also allows this:

const laxy = require("laxy");
const lodash = laxy(() => require("lodash"))();

[fabiospampinato]

We can't have special handling for all these not statically analyse-able code. This is out of scope for webpack.

I could correctly bundle that piece of code by hand, shouldn't WebPack ideally be able to do the same?

Regardless of the difficulty of this particular problem I don't understand how being able to bundle this piece of code can possibly be out of scope for a bundler.

import-lazy is only used by 33 modules.

Some of those are quite popular, if I can't get those to be webpack-compatible (I can't, I tried already), I think the only option left to me is to fork them, which I'd argue should be avoided if at all possible.

[fabiospampinato]

I think the only option left to me is to fork them

Unless maybe I could write a babel transform or something that transforms that code into something WebPack can understand?

That would be quite cumbersome to use though, I expect basically nobody other than the plugin author would use the plugin. Plus sometimes WebPack's config is generated programmatically by some third-party tool and it's not easy to extend.

What if each individual module had the power to inject some custom plugins into WebPack's configuration? Maybe this could solve the issue in a powerful enough way without any special cases?

[sokra]

We can't have special handling for all these not statically analyse-able code. This is out of scope for webpack.

You can write a webpack plugin on make webpack understand import-lazy. It's just out-of-scope for the core.

Note that EcmaScript Modules disallow non-statically analyse-able imports anyway. So the long-term direction of modules goes towards statically analyse-able imports.

[sokra]

You can ask on the ncc issue tracker. They have a lot of special-handling for such cases. Maybe they want to add it.

[webpack-bot]

This issue had no activity for at least three months.

It's subject to automatic issue closing if there is no activity in the next 15 days.

[fabiospampinato]

I hate these bots

[webpack-bot]

Issue was closed because of inactivity.

If you think this is still a valid issue, please file a new issue with additional information.