5.0.0-rc.3 fails with tslib

[philcockfield]

Bug report

What is the current behavior?

Running webpack@5.0.0-rc.3 fails when importing rxjs (which uses tslib):

---

If the current behavior is a bug, please provide the steps to reproduce.

Details of this error are reproducible in https://github.com/philcockfield/webpack5-tslib-error
The demo repo is a minimal webpack configuration using ts-loader that imports rxjs. It also behaves this way with vanilla JS and babel loaders.

---

What is the expected behavior?
The page loads with no errors. This demo repo works fine with webpack@4.44.2 and then cleanly fails by flipping the version up to 5.0.0-rc.3

---

Other relevant information:
webpack version: 5.0.0-rc.3, 5.0.0-rc.4
Node.js version: 12.16.3
Operating System: MacOS (10.15.7)
Additional tools: -

[aariacarterweir]

Seeing this too with @sentry/browser

[sokra]

@orta This is caused by microsoft/tslib#127

tslib/modules/index.js contains a import tslib from '../tslib.js';
but tslib/tslib.js doesn't contain a default export. It only contains named exports.
Becauses of this tslib is undefined in tslib/modules/index.js.
webpack 4 is unaffected because it doesn't support the exports field.
Node.js is unaffected because it doesn't support the __esModule flag.
But in combination they lead to this error.

Unrelated from this adding an exports field to a package.json is most often a breaking change, because it breaks e. g. import "tslib/tslib.js". I would recommend to revert the backport.

[weswigham]

@sokra the exports pattern in use has a directory reexport, so import "tslib/tslib.js" should continue to function as it used to.

The issue is solely because webpack and node disagree on what shape importing a cjs module should take. In node, when an es module imports a cjs module, the cjs module is made available, in full, as the default value of the import. Some statically determinable names may also be made available as named exports, as of a recent patch, but tslib's exports aren't statically determinable (because of its UMD wrapper pattern), so in node it won't have any named exports. Meanwhile in webpack, only named exports get made.... these two views of the module system are mutually incompatible. Either node or webpack would need to change:

• If node could get named exports without static analysis and use the values available at runtime, then we could use named exports everywhere (as you suggest) and it'd be fine. (In fact, if node did this, we wouldn't need our exports redirection to support node's esm at all!)
• If webpack made the cjs module available as the default, as node does, then we could use the default as we currently do, and it'd be fine.

One of the two needs to change, though, there's nothing we could do that isn't a major break in some other way that fixes it.

[guybedford]

I thought webpack did make the default available when importing CommonJS modules? Is that really the root cause here?

[weswigham]

Yeah, it would seem to be. Both babel and TS (with esModuleInterop) make the module available as the default when importing cjs modules; it would seem that webpack does not.

[guybedford]

I specificaly tested this and it seemed to always include default. Is it perhaps because there is an __esModule export which is blocking the normal default set?

[guybedford]

Further, if tslib isn't being imported but it is being require'd the "import" path shouldn't be applying in exports in the first place at all. So I'm confused why it's even using the module verison to begin with.

[alexander-akait]

@guybedford exports works for import and require

[guybedford]

"import" should not be matched when using a require() expression, it is very clearly defined not to mean that.

[alexander-akait]

And we don't do it

[guybedford]

rxjs is CommonJS loading tslib - so it shouldn't be hitting the "import" path in require('tslib'), but it sounds like it is?

[guybedford]

I see rxjs has a modules path. So it's just the issue in #11613 (comment) then. Ok glad to hear "imports" doesn't apply unnecessarily and thanks for clarifying @evilebottnawi.

It should be possible to support default for __esModule CommonJS. This leaves only one conflict case where a module has both __esModule and default. On this edge case I understand Node.js and bundlers likely will have to just remain in conflict. But we can solve it right up to that edge at least, which is where all the work on both sides finally gets us, that one small gap :)

[alexander-akait]

@guybedford don't worry we will found better way, you can see blocking on the right side above