just noticed, a build of mine stopped since the release of v3.2.4.
repro:
// webpack.config.js
import { ProvidePlugin } from 'webpack'
new ProvidePlugin() // TypeError: ProvidePlugin is not a constructor
console.log(typeof ProvidePlugin) // object
node ./node_modules/.bin/webpack --config-register esm
import * as ns from 'webpack'
console.log(ns.ProvidePlugin) // ProvidePlugin: [Getter]
more info:
https://github.com/webpack/webpack/blob/v4.29.3/lib/ProvidePlugin.js
exported:
https://github.com/webpack/webpack/blob/v4.29.3/lib/webpack.js#L88
for some reason I couldn't repro in node repl node -r esm, only when run with webpack.
update, just checked:
node -r esm webpack.config.js # works
@jdalton just noticed you added a test case using DefinePlugin -- and here is the crazy part: I use DefinePlugin in another project and noticed it worked with v3.2.4. so I went back to the other failing project with v3.2.4 and tried DefinePlugin there as well, and it worked!
console.log(typeof DefinePlugin) // function
console.log(typeof ProvidePlugin) // object
_update:_
just tried a build from master [latest] and the issue appears to be fixed.
Thanks @dnalborczyk!
Updated the test to use ProvidePlugin.
no problem. I just looked at both definitions, and I see no differences. do you know why one behaves different over the other?
do you know why one behaves different over the other?
Nope ๐คทโโ๏ธ
Nope ๐คทโโ๏ธ
๐
I wonder if it's v8-compile-cache ...
that being said, not sure why it would work for one, but not the other :confused:
TypeError: ProvidePlugin is not a constructor
at Object.<anonymous> (file:///Users/daniel/dev/project/packages/web/webpack.config.js:33:23)
at Generator.next (<anonymous>)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:745:10)
at Module.load (internal/modules/cjs/loader.js:626:32)
at tryModuleLoad (internal/modules/cjs/loader.js:566:12)
at Function.Module._load (internal/modules/cjs/loader.js:558:3)
at Module.require (internal/modules/cjs/loader.js:663:17)
at require (file:///Users/daniel/dev/project/node_modules/v8-compile-cache/v8-compile-cache.js:159:20)
at WEBPACK_OPTIONS (file:///Users/daniel/dev/project/node_modules/webpack-cli/bin/convert-argv.js:113:13)
at requireConfig (file:///Users/daniel/dev/project/node_modules/webpack-cli/bin/convert-argv.js:117:6)
at file:///Users/daniel/dev/project/node_modules/webpack-cli/bin/convert-argv.js:124:17
at Array.forEach (<anonymous>)
at module.exports (file:///Users/daniel/dev/project/node_modules/webpack-cli/bin/convert-argv.js:122:15)
at yargs.parse (file:///Users/daniel/dev/project/node_modules/webpack-cli/bin/cli.js:228:39)
at Object.parse (file:///Users/daniel/dev/project/node_modules/webpack-cli/node_modules/yargs/yargs.js:567:18)
at file:///Users/daniel/dev/project/node_modules/webpack-cli/bin/cli.js:206:8
at Object.<anonymous> (file:///Users/daniel/dev/project/node_modules/webpack-cli/bin/cli.js:500:3)
at Module._compile (internal/modules/cjs/loader.js:734:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:745:10)
at Module.load (internal/modules/cjs/loader.js:626:32)
at tryModuleLoad (internal/modules/cjs/loader.js:566:12)
at Function.Module._load (internal/modules/cjs/loader.js:558:3)
at Module.require (internal/modules/cjs/loader.js:663:17)
at require (internal/modules/cjs/helpers.js:20:18)
at Object.<anonymous> (file:///Users/daniel/dev/project/node_modules/webpack/bin/webpack.js:156:2)
at Module._compile (internal/modules/cjs/loader.js:734:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:745:10)
at Module.load (internal/modules/cjs/loader.js:626:32)
just looked into it a little more. it seems the issue is unrelated to webpack!
I deleted the file ProvidePlugin.js from node_modules/webpack/lib, and esm doesn't seem to notice.
named import:
// webpack.config.js (but can be any file)
import { ProvidePlugin } from 'webpack'
console.log(ProvidePlugin)
ESM_DISABLE_CACHE=true node -r esm webpack.config.js
undefined
md5-dcd07a4d052de9b9577c57f60138ae3d
```bash
ESM_DISABLE_CACHE=true node -r esm webpack.config.js
[Module] {
AutomaticPrefetchPlugin: [Function: AutomaticPrefetchPlugin],
BannerPlugin: [Function: BannerPlugin],
...
ProvidePlugin: <uninitialized>
...
md5-89488231ad035d95062bb3506145993e
```bash
ESM_DISABLE_CACHE=true node -r esm webpack.config.js
Error: Cannot find module './ProvidePlugin'
md5-cb676d4893a363eb0a58ac86b1b043bc
```bash
ESM_DISABLE_CACHE=true node -r esm webpack.config.js
# or without esm:
# node webpack.config.js
Error: Cannot find module './ProvidePlugin'
_update_:
this also happens with current HEAD of master.
is the problem maybe the way the plugins are dynamically required? ๐ค
I'm confused. Did the patch not resolve this? The patch resolved the issue where require() was being triggered in the parse phase (something not supposed to happen) which caused an empty module.exports to be recorded instead of the fully realized version.
ah, gotcha. yes, the patch resolved the original issue.
but there seems to be still an underlying additional issue.
if you delete ProvidePlugin from node_modules/webpack/lib, as described above, esm does not error.
// webpack.config.js (but can be any file)
import { ProvidePlugin } from 'webpack'
console.log(ProvidePlugin)
ESM_DISABLE_CACHE=true node -r esm webpack.config.js
undefined # but should error file not found
I believe this is also in master.
I only looked through it because it bothered me that DefinePlugin worked, but ProvidePlugin did not -- even though they appear to be same/similar. so with esm v3.2.4 I changed some code in ProvidePlugin to see what might cause the problem, but I couldn't see any difference in behavior, until I finally deleted the file with still no differences.
Then I checked the same with master, and I noticed the above.
@jdalton should I rather file a new issue?
I can confirm, the original issue is fixed! ๐
the follow-up issue unfortunately not quite yet. good thing is, it doesn't prevent anyone from using this version, it's just exporting the wrong (undefined) thing, when it should throw an error.
the follow-up issue unfortunately not quite yet.
I checked on that and it was working as designed.
it's just exporting the wrong (
undefined) thing, when it shouldthrow an error.
We prevent the error and treat it as undefined. You can see this with a simple demo:
module.exports = { get a() { throw new Error } }
then node -r esm and in the REPL:
import { a } from "./foo"
the value of a is undefined.
ah, I see. wouldn't it be better to let the error bubble up, similar to cjs-requiring the module? if not, just out of curiosity, what is the reason it shouldn't/or can't be done?
After reviewing some of our unit tests I think it was our intent to originally bubble up the errors. So the current behavior of swallowing them can be seen as a bug. Patched/Test https://github.com/standard-things/esm/commit/422937235e10099f12447ff45fc1c509c21cfdb9.
Update:
v3.2.6 is released ๐
Most helpful comment
After reviewing some of our unit tests I think it was our intent to originally bubble up the errors. So the current behavior of swallowing them can be seen as a bug. Patched/Test https://github.com/standard-things/esm/commit/422937235e10099f12447ff45fc1c509c21cfdb9.
Update:
v3.2.6 is released ๐