Parsing of `import()` fails in 4.29.0 (Compilation issue, related to dynamic import)
See original GitHub issueBug report
What is the current behavior?
I’ve updated to v4.29.0, and my code is no longer compiling.
Error:
Module parse failed: Unexpected token (11:10)
You may need an appropriate loader to handle this file type.
| var AsyncHome = asyncComponent(appendAsyncReducer, epicSubject$, function () {
| return process.env.SERVER ? require('./home')
> : import(
| /* webpackChunkName: "books" */
| './home');
@ ./server/ssr.js 15:0-34 167:25-34
@ ./server/index.js
If I revert to v4.28.2, it works again.
If the current behavior is a bug, please provide the steps to reproduce.
- Clone
https://github.com/Dbuggerx/react-book-search-sample.git
npm i
and compile the code (npm run start-server
ornpm run start
) - it should work- Now, install webpack v4.29.0 and try to compile again
What is the expected behavior? It should compile the code without errors, as it was doing on v4.28.2
Other relevant information: webpack version: v4.29.0 Node.js version: v10.15.0 Operating System: Fedora linux 29
Issue Analytics
- State:
- Created 5 years ago
- Reactions:418
- Comments:171 (24 by maintainers)
Top Results From Across the Web
webpack - vue.js - dynamic imports results in error: Support for ...
I recognise this error from when I was playing with Webpack on its own a few months ago, so I knew I had...
Read more >7.5.0 Released: dynamic import and F# pipelines - Babel
Today we are releasing Babel 7.5.0!
Read more >Dynamic Imports in Vue.js for better performance - VueDose
Tutorial on code splitting using dynamic import in vue.js applications in order to have better performance.
Read more >When magic fails — a programmer grows | by Yonatan Kra
The babel loader tried to parse our import statements, that's what happened. What's its problem? It's something called dynamic import() .
Read more >fonttools · PyPI
[feaLib] Have fontTools feaLib script exit with error code when build fails (#2459) ... [ttLib] when importing XML, only set sfntVersion if the...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Running these commands fixes the problem in your repro @Dbuggerx
It seem to be a npm problem.
Here is an explanation:
webpack
depends onacorn@^6.0.5
andacorn-dynamic-import
.acorn-dynamic-import
has apeerDependency
toacorn
. The peer dependency marks thatacorn-dynamic-import
wants to use theacorn
dependency ofwebpack
.Normally this works fine, but in your repo npm created a tree like this:
Note the deduped
acorn@6.0.4
dependency was moved/hoisted to the rootnode_modules
directory and webpack got it’s ownacorn@6.0.5
dependency in it’s ownnode_modules
. So far fine, but npm has chosen to hoist theacorn-dynamic-import
dependency to the rootnode_modules
directory. Now it no longer uses the sameacorn
dependency as webpack does. The version doesn’t matter so much, but the instance equality.I claim that npm should not hoist
acorn-dynamic-import
here as it has apeerDependency
on acorn. It must ensure that webpack and acorn-dynamic-import have access to the sameacorn
dependency.Running the commands above fixes the problem as it pushes all acorn dependency to the same version and allowing to hoist the acorn dependency in webpack too. It’s more a workaround, but should work. It changes the tree to:
same here, downgrading to 4.28 works