Closed WolfspiritM closed 2 years ago
Can you provide example how we can reproduce it?
I sadly can't produce a good example cause the source I'm using is private and it seems like the reason for that is really the size.
I tried to investigate further and it seems like the reason really is a too large "source".
I have a source that is has a length of 11846003 characters which causes that issue. As these streamChunk functions seem to be called asynchronously I just ended up having the small line as the last one before the crash. However the problem is with that large file (and if out of some reason that file works then it happens with the next one wich is twice as large). I exported that file and called new RawSource(filecontent) and then streamChunks manually but that didn't cause the issue.
In some rare cases it seems to work. I have no idea how to procede. I tried to make a reproducable example via a new repository but I don't have the error there.
I think the source is just too large for the regex (as it always happens with the String.match function) but I actually have no idea why it works when calling RawSource manually.
Any idea?
How often does this happen? Do you build application in dev or production mode? Do you use webpack dev server when got this problem? Do you generate source maps? What is value of devtool
?
How often does this happen?
About 9 out of 10 times. Very often. With 5.46.0 it never happened.
Do you build application in dev or production mode?
It happens when building the storybook static version. According to their docs it's building production mode.
Do you use webpack dev server when got this problem?
No. Also using storybook watch mode works fine.
Do you generate source maps? What is value of devtool?
Value of devtool is cheap-module-source-map
(which seems to be the storybook default).
When setting devtool to undefined before the build the build succeeds all the time.
I assume there is a huge sourcemap that is causing that issue.
Maybe you are right, can you try to debug values passed to at String.match
?
I am afraid it can be ddos regexp...
The regexp passed is the one from here: https://github.com/webpack/webpack-sources/blob/10d5dae6a3c907b93f80c1a51d450f55214b09f4/lib/helpers/streamChunksOfRawSource.js#L10
while the source string where the match is applied to is the 11846003 long string.
It starts with:
const __WEBPACK_NAMESPACE_OBJECT__ = JSON.parse('
And seems to be a very huge json with properties like name, type, description, methods, args. I guess that's a source map.
What I find interesting however is that I wrote that huge file to a textfile and tried a simple script to reproduce it by doing:
const t = require('webpack-sources');
const fs = require('fs');
const file = fs.readFileSync('test.js', "utf8");
var s = new t.RawSource(file);
s.streamChunks({}, () => {}, () => {}, () => {});
And that works without problems...so there must be something else in play. Either an already large call stack (but it doesn't seem to be that large) or maybe the parallel execution that causes it to trip?!
Either an already large call stack (but it doesn't seem to be that large)
I think this... We need rewrite this, but it can't be very easy
We're having the same issue in our Angular 12 project after updating our packages. I initially thought it had to do with SASS as picked up in other threads (https://stackoverflow.com/questions/68756057/maximum-call-stack-size-exceeded-in-streamchunksofsourcemap-js), however, this makes more sense.
This happened in multiple branches when updating different packages, so it makes sense that our project might have reached the size limit that causes this issue. I currently can't build our project at all.
Are there any short-term workarounds for this?
No short-term workaround, we need to fix it here
Downgrading Angular to 12.0.5 worked for me. Why would this resolve the issue though?
Maybe you can provide steps to reproduce? We really need to investigate it
Unfortunately it's a private repository and I won't be able to.
We can always try to use the angular stress-test project, it might be big enough. Work is a bit hectic right now, I'll try to set it up in a few days.
If anyone else wants to attempt it, I just know that updating to the latest Angular CLI version is what caused this. Reverting to 12.0.5 fixed it.
I think I have time today. I'm not familiar with the angular stress-test project but I'm sure I can find it. I'll take a stab at it and let you know.
Unfortunately no luck with the angular-stress-test project, the maximum I ran was 100 modules with 10.000 components. Both the ng build
and npm run build:prod
which equals to ng build --configuration production
(which was seen as one of the primary causes for the issue when it was first noticed) seem to run fine. They take their sweet time, but end up in a build just around 7mb which is fine.
No compilation or packing breaks here. So it must be more complex then the auto generated modules and components to get either Angular or Webpack to go into the maximum stack call size error.
Unless it's related to ng-packagr. I will try upgrading only that in our codebase and checking if it happens or not.
I've ran into similar issues in a project that did not depend on ng-packagr, I think I've seen multiple issues being opened in the @angular/angular repository with similar issues as well, most of these were not directly external library dependent.
There's definitely something in between Angular's compilation step and the handoff to Webpack where either one of them goes wrong.
I've heard that the whole sourcemapping part in Webpack has been overhauled recently, that could be a part of it; but of course: No repro, no clue.
Got the same issue today with one of our internal lib projects with playground app. Lib itself seems to build fine, but running the app with ng serve
gives the error (production build works fine, though).
What I did prior to getting the issue: added a bunch of re-exports of Kendo UI in another library which is used in current lib, also updated Angular to v12.2.2.
Tried rolling back to v12.2.1 and at first it seemed like the problem was fixed, but it reappeared some hours later, so I had to switch to sourceMap: false
for the playground app to build.
Also about the theory that build size might be the problem: I think the issue is somehow related to using ng seve
and its unminified output, because ng serve
-ing my playground app (with sourceMap=false) showed Initial Total of ~21.56 MB, which is pretty huge by itself.
Let's not forget we're here in the issues of webpack-sources
, we may want to find the related issue mentioned in Angular's repository and continue this discussion and exchange of experiences there. Not having a reproduction makes it incredibly hard to determine if this issue is with Angular or with Webpack, or in the middle of both.
May I recommend we use https://github.com/angular/angular-cli/issues/21599 this one for the time being? Of course we can combine our knowledge and experiences to try and get to a reproduction of the problem. If this then turns out to be more Webpack related, at least then we bring the information back here.
Maybe you can also provide stack trace? Based on
at ItemCacheFacade.get (\node_modules\webpack\lib\CacheFacade.js:117:15)
at getTaskForFile (\node_modules\webpack\lib\SourceMapDevToolPlugin.js:84:30)
something wrong with source maps and caches
Absolutely!
Maximum call stack size exceeded
HookWebpackError: Maximum call stack size exceeded
at makeWebpackError (/Users/bjorn/Dev/clientapp/src/node_modules/webpack/lib/HookWebpackError.js:48:9)
at /Users/bjorn/Dev/clientapp/src/node_modules/webpack/lib/Compilation.js:2515:12
at eval (eval at create (/Users/bjorn/Dev/clientapp/src/node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:114:1)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:95:5)
-- inner error --
RangeError: Maximum call stack size exceeded
at String.match (<anonymous>)
at streamChunksOfRawSource (/Users/bjorn/Dev/clientapp/src/node_modules/webpack/node_modules/webpack-sources/lib/helpers/streamChunksOfRawSource.js:14:25)
at module.exports (/Users/bjorn/Dev/clientapp/src/node_modules/webpack/node_modules/webpack-sources/lib/helpers/streamChunksOfRawSource.js:40:5)
at RawSource.streamChunks (/Users/bjorn/Dev/clientapp/src/node_modules/webpack/node_modules/webpack-sources/lib/RawSource.js:56:10)
at module.exports (/Users/bjorn/Dev/clientapp/src/node_modules/webpack/node_modules/webpack-sources/lib/helpers/streamChunks.js:13:17)
at ReplaceSource.streamChunks (/Users/bjorn/Dev/clientapp/src/node_modules/webpack/node_modules/webpack-sources/lib/ReplaceSource.js:176:44)
at module.exports (/Users/bjorn/Dev/clientapp/src/node_modules/webpack/node_modules/webpack-sources/lib/helpers/streamChunks.js:13:17)
at streamAndGetSourceAndMap (/Users/bjorn/Dev/clientapp/src/node_modules/webpack/node_modules/webpack-sources/lib/helpers/streamAndGetSourceAndMap.js:27:53)
at CachedSource.streamChunks (/Users/bjorn/Dev/clientapp/src/node_modules/webpack/node_modules/webpack-sources/lib/CachedSource.js:208:35)
at module.exports (/Users/bjorn/Dev/clientapp/src/node_modules/webpack/node_modules/webpack-sources/lib/helpers/streamChunks.js:13:17)
at ConcatSource.streamChunks (/Users/bjorn/Dev/clientapp/src/node_modules/webpack/node_modules/webpack-sources/lib/ConcatSource.js:112:55)
at module.exports (/Users/bjorn/Dev/clientapp/src/node_modules/webpack/node_modules/webpack-sources/lib/helpers/streamChunks.js:13:17)
at streamAndGetSourceAndMap (/Users/bjorn/Dev/clientapp/src/node_modules/webpack/node_modules/webpack-sources/lib/helpers/streamAndGetSourceAndMap.js:27:53)
at CachedSource.streamChunks (/Users/bjorn/Dev/clientapp/src/node_modules/webpack/node_modules/webpack-sources/lib/CachedSource.js:208:35)
at module.exports (/Users/bjorn/Dev/clientapp/src/node_modules/webpack/node_modules/webpack-sources/lib/helpers/streamChunks.js:13:17)
at ConcatSource.streamChunks (/Users/bjorn/Dev/clientapp/src/node_modules/webpack/node_modules/webpack-sources/lib/ConcatSource.js:112:55)
Same with webpack 5.51.1
RangeError: Maximum call stack size exceeded
at String.match (<anonymous>)
at streamChunksOfSourceMapFull (D:\dev\projectname\src\node_modules\webpack\node_modules\webpack-sources\lib\helpers\streamChunksOfSourceMap.js:21:23)
at module.exports (D:\dev\projectname\src\node_modules\webpack\node_modules\webpack-sources\lib\helpers\streamChunksOfSourceMap.js:389:6)
at nameIndexMapping.<computed> (D:\dev\projectname\src\node_modules\webpack\node_modules\webpack-sources\lib\helpers\streamChunksOfCombinedSourceMap.js:271:5)
at streamChunksOfSourceMapFinal (D:\dev\projectname\src\node_modules\webpack\node_modules\webpack-sources\lib\helpers\streamChunksOfSourceMap.js:265:3)
at module.exports (D:\dev\projectname\src\node_modules\webpack\node_modules\webpack-sources\lib\helpers\streamChunksOfSourceMap.js:382:6)
at streamChunksOfCombinedSourceMap (D:\dev\projectname\src\node_modules\webpack\node_modules\webpack-sources\lib\helpers\streamChunksOfCombinedSourceMap.js:54:9)
at SourceMapSource.streamChunks (D:\dev\projectname\src\node_modules\webpack\node_modules\webpack-sources\lib\SourceMapSource.js:197:11)
js:17:33)
at SourceMapSource.sourceAndMap (D:\dev\projectname\src\node_modules\webpack\node_modules\webpack-sources\lib\SourceMapSource.js:188:10)
Also can you provide npm ls webpack-sources
Absolutely!
npm ls webpack-sources
clientapp@0.0.0
├─┬ @angular-devkit/build-angular@12.2.1
│ ├─┬ license-webpack-plugin@2.3.20
│ │ └── webpack-sources@1.4.3
│ ├─┬ webpack@5.50.0
│ │ └── webpack-sources@3.2.0
│ └─┬ webpack-subresource-integrity@1.5.2
│ └── webpack-sources@1.4.3 deduped
└─┬ @nrwl/nest@12.3.4
└─┬ @nrwl/node@12.3.4
├─┬ copy-webpack-plugin@6.0.3
│ └── webpack-sources@1.4.3 deduped
├─┬ license-webpack-plugin@2.1.2
│ └── webpack-sources@1.4.3 deduped
└─┬ webpack@4.42.0
├─┬ terser-webpack-plugin@1.4.5
│ └── webpack-sources@1.4.3 deduped
└── webpack-sources@1.4.3 deduped
Hope this aligns nicely. Already noticed that there's two or three versions being used in different parts. Think I saw a very recent commit on Angular's repo maybe updating that.
webpack@4.42.0
and webpack@5.50.0
, you have mixed webpack versions, I think problem in this
May be some package uses require('webpack-source')
for webpack v4 (now you should get it using compiler.webpack.sources
), but due package manager hoist logic on the top webpack-sources@3.2.0
, so API is broken
Hmm that seems to be an issue with @nrwl/nest
then, which I don't think we need. I could see if I can get rid of that and what that does to the npm ls
.
You mean API broken as in the libraries that have Webpack as a devDependency?
You mean API broken as in the libraries that have Webpack as a devDependency?
Yes
The webpack-sources@3.2.0
is the expected one to be working correctly with Webpack 5?
After removing @nrwl/nest
and trying to do another run; it breaks in exactly the same way.
HookWebpackError: Maximum call stack size exceeded
at makeWebpackError (/Users/bjorn/Dev/omniplan/Omniplan.PersonalFinancePlanner/src/Omniplan.PersonalFinancePlanner/clientapp/node_modules/webpack/lib/HookWebpackError.js:48:9)
at /Users/bjorn/Dev/omniplan/Omniplan.PersonalFinancePlanner/src/Omniplan.PersonalFinancePlanner/clientapp/node_modules/webpack/lib/Compilation.js:2515:12
at eval (eval at create (/Users/bjorn/Dev/omniplan/Omniplan.PersonalFinancePlanner/src/Omniplan.PersonalFinancePlanner/clientapp/node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:114:1)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:95:5)
-- inner error --
RangeError: Maximum call stack size exceeded
at String.match (<anonymous>)
at streamChunksOfRawSource (/Users/bjorn/Dev/omniplan/Omniplan.PersonalFinancePlanner/src/Omniplan.PersonalFinancePlanner/clientapp/node_modules/webpack/node_modules/webpack-sources/lib/helpers/streamChunksOfRawSource.js:14:25)
at module.exports (/Users/bjorn/Dev/omniplan/Omniplan.PersonalFinancePlanner/src/Omniplan.PersonalFinancePlanner/clientapp/node_modules/webpack/node_modules/webpack-sources/lib/helpers/streamChunksOfRawSource.js:40:5)
at RawSource.streamChunks (/Users/bjorn/Dev/omniplan/Omniplan.PersonalFinancePlanner/src/Omniplan.PersonalFinancePlanner/clientapp/node_modules/webpack/node_modules/webpack-sources/lib/RawSource.js:56:10)
at module.exports (/Users/bjorn/Dev/omniplan/Omniplan.PersonalFinancePlanner/src/Omniplan.PersonalFinancePlanner/clientapp/node_modules/webpack/node_modules/webpack-sources/lib/helpers/streamChunks.js:13:17)
at ReplaceSource.streamChunks (/Users/bjorn/Dev/omniplan/Omniplan.PersonalFinancePlanner/src/Omniplan.PersonalFinancePlanner/clientapp/node_modules/webpack/node_modules/webpack-sources/lib/ReplaceSource.js:176:44)
at module.exports (/Users/bjorn/Dev/omniplan/Omniplan.PersonalFinancePlanner/src/Omniplan.PersonalFinancePlanner/clientapp/node_modules/webpack/node_modules/webpack-sources/lib/helpers/streamChunks.js:13:17)
at streamAndGetSourceAndMap (/Users/bjorn/Dev/omniplan/Omniplan.PersonalFinancePlanner/src/Omniplan.PersonalFinancePlanner/clientapp/node_modules/webpack/node_modules/webpack-sources/lib/helpers/streamAndGetSourceAndMap.js:27:53)
at CachedSource.streamChunks (/Users/bjorn/Dev/omniplan/Omniplan.PersonalFinancePlanner/src/Omniplan.PersonalFinancePlanner/clientapp/node_modules/webpack/node_modules/webpack-sources/lib/CachedSource.js:208:35)
at module.exports (/Users/bjorn/Dev/omniplan/Omniplan.PersonalFinancePlanner/src/Omniplan.PersonalFinancePlanner/clientapp/node_modules/webpack/node_modules/webpack-sources/lib/helpers/streamChunks.js:13:17)
at ConcatSource.streamChunks (/Users/bjorn/Dev/omniplan/Omniplan.PersonalFinancePlanner/src/Omniplan.PersonalFinancePlanner/clientapp/node_modules/webpack/node_modules/webpack-sources/lib/ConcatSource.js:112:55)
at module.exports (/Users/bjorn/Dev/omniplan/Omniplan.PersonalFinancePlanner/src/Omniplan.PersonalFinancePlanner/clientapp/node_modules/webpack/node_modules/webpack-sources/lib/helpers/streamChunks.js:13:17)
at streamAndGetSourceAndMap (/Users/bjorn/Dev/omniplan/Omniplan.PersonalFinancePlanner/src/Omniplan.PersonalFinancePlanner/clientapp/node_modules/webpack/node_modules/webpack-sources/lib/helpers/streamAndGetSourceAndMap.js:27:53)
at CachedSource.streamChunks (/Users/bjorn/Dev/omniplan/Omniplan.PersonalFinancePlanner/src/Omniplan.PersonalFinancePlanner/clientapp/node_modules/webpack/node_modules/webpack-sources/lib/CachedSource.js:208:35)
at module.exports (/Users/bjorn/Dev/omniplan/Omniplan.PersonalFinancePlanner/src/Omniplan.PersonalFinancePlanner/clientapp/node_modules/webpack/node_modules/webpack-sources/lib/helpers/streamChunks.js:13:17)
at ConcatSource.streamChunks (/Users/bjorn/Dev/omniplan/Omniplan.PersonalFinancePlanner/src/Omniplan.PersonalFinancePlanner/clientapp/node_modules/webpack/node_modules/webpack-sources/lib/ConcatSource.js:112:55)
npm ls webpack-sources
clientapp@0.0.0 /clientapp
└─┬ @angular-devkit/build-angular@12.2.1
├─┬ license-webpack-plugin@2.3.20
│ └── webpack-sources@1.4.3
├─┬ webpack@5.50.0
│ └── webpack-sources@3.2.0
└─┬ webpack-subresource-integrity@1.5.2
└── webpack-sources@1.4.3 deduped
Might it be that the webpack-sources@1.4.3
is causing issues here too? I might just install a devDependency at 3.2.0
and see what that does.
Might it be that the webpack-sources@1.4.3 is causing issues here too? I might just install a devDependency at 3.2.0 and see what that does.
Yes, let's try to remove it to, just for test
Yeah the problem here might be that both webpack-subresource-integrity
and license-webpack-plugin
depend on an older version, so they just may need to be updated. This already might've been done in the Angular repo, so I'll check that commit (and link it here).
Seems to have been updated already:
"license-webpack-plugin": "2.3.21",
"webpack-subresource-integrity": "5.0.0"
Now I'm not sure if 2.3.21
for license will bring 5.0.0
support, or if it matters. But we might be getting to a more aligned setup already so we can spot for actual bugs.
Confirmed that license-webpack-plugin
has not been updated to use the newer webpack-sources
library yet. I'm not sure if this will be the cause of any breaks.
Can you try to disable this plugin and run webpack again?
I'm afraid that's quite deep into Angular's inner workings and I don't know how to disable it. (For completeness sake; there's no default Webpack configuration, this one is auto generated by the Angular CLI if I understand correctly.)
I'll take a look for debugging purposes and see what I can find. But if the issue now points that there's a mismatch between the versions used from deeper dependencies within Angular, that feels like a more suitable spot to make an issue and provide the info we have brought up.
/cc @alan-agius4 maybe you can help here
Oh that could also work, I was just about to write a post on an open issue with the same error message and point to this issue there.
To disable the license-webpack-plugin
you can run ng build
with the --no-extract-licenses
argument.
Tip: if you think that this is caused by an outdated plugin, you can use yarn resolutions to confirm if it was fixed in a newer version.
https://classic.yarnpkg.com/en/docs/selective-version-resolutions/
No luck unfortunately @alexander-akait.
└ ❯ update/angular-12.2 ↑78 ❯ × ❯ npm run build:prod
> clientapp@0.0.0 build:prod /Users/bjorn/Dev/clientapp/src/clientapp
> npx nx build --configuration production --no-extract-licenses --verbose
> nx run clientapp:build:production --no-extractLicenses --verbose
✔ Browser application bundle generation complete.
Maximum call stack size exceeded
HookWebpackError: Maximum call stack size exceeded
at makeWebpackError (/Users/bjorn/Dev/clientapp/src/clientapp/node_modules/webpack/lib/HookWebpackError.js:48:9)
at /Users/bjorn/Dev/clientapp/src/clientapp/node_modules/webpack/lib/Compilation.js:2515:12
at eval (eval at create (/Users/bjorn/Dev/clientapp/src/clientapp/node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:88:1)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:95:5)
-- inner error --
RangeError: Maximum call stack size exceeded
at String.match (<anonymous>)
at streamChunksOfRawSource (/Users/bjorn/Dev/clientapp/src/clientapp/node_modules/webpack-sources/lib/helpers/streamChunksOfRawSource.js:14:25)
at module.exports (/Users/bjorn/Dev/clientapp/src/clientapp/node_modules/webpack-sources/lib/helpers/streamChunksOfRawSource.js:40:5)
at RawSource.streamChunks (/Users/bjorn/Dev/clientapp/src/clientapp/node_modules/webpack-sources/lib/RawSource.js:56:10)
at module.exports (/Users/bjorn/Dev/clientapp/src/clientapp/node_modules/webpack-sources/lib/helpers/streamChunks.js:13:17)
at ReplaceSource.streamChunks (/Users/bjorn/Dev/clientapp/src/clientapp/node_modules/webpack-sources/lib/ReplaceSource.js:176:44)
at module.exports (/Users/bjorn/Dev/clientapp/src/clientapp/node_modules/webpack-sources/lib/helpers/streamChunks.js:13:17)
at streamAndGetSourceAndMap (/Users/bjorn/Dev/clientapp/src/clientapp/node_modules/webpack-sources/lib/helpers/streamAndGetSourceAndMap.js:27:53)
at CachedSource.streamChunks (/Users/bjorn/Dev/clientapp/src/clientapp/node_modules/webpack-sources/lib/CachedSource.js:208:35)
at module.exports (/Users/bjorn/Dev/clientapp/src/clientapp/node_modules/webpack-sources/lib/helpers/streamChunks.js:13:17)
at ConcatSource.streamChunks (/Users/bjorn/Dev/clientapp/src/clientapp/node_modules/webpack-sources/lib/ConcatSource.js:112:55)
at module.exports (/Users/bjorn/Dev/clientapp/src/clientapp/node_modules/webpack-sources/lib/helpers/streamChunks.js:13:17)
at streamAndGetSourceAndMap (/Users/bjorn/Dev/clientapp/src/clientapp/node_modules/webpack-sources/lib/helpers/streamAndGetSourceAndMap.js:27:53)
at CachedSource.streamChunks (/Users/bjorn/Dev/clientapp/src/clientapp/node_modules/webpack-sources/lib/CachedSource.js:208:35)
at module.exports (/Users/bjorn/Dev/clientapp/src/clientapp/node_modules/webpack-sources/lib/helpers/streamChunks.js:13:17)
at ConcatSource.streamChunks (/Users/bjorn/Dev/clientapp/src/clientapp/node_modules/webpack-sources/lib/ConcatSource.js:112:55)
npm ls webpack-sources
clientapp@0.0.0
├─┬ @angular-devkit/build-angular@12.2.3
│ ├─┬ license-webpack-plugin@2.3.20
│ │ └── webpack-sources@1.4.3
│ ├─┬ webpack@5.50.0
│ │ └── webpack-sources@3.2.0 deduped
│ └─┬ webpack-subresource-integrity@1.5.2
│ └── webpack-sources@1.4.3
└── webpack-sources@3.2.0
This leaves the webpack-subresource-integrity
lower in the tree, but I'm pretty sure I saw in a commit on @angular/angular-cli that this was already fixed.
@Bjeaurn maybe you can try it from main/master, or update it locally (inside node_modules
) and try again?
webpack-subresource-integrity
is only used when SRI is enabled, is it the case for your project?
Can you try to disable both webpack-subresource-integrity
and license-webpack-plugin
?
ng build --configuration production --no-extract-licenses --no-subresource-integrity
@alexander-akait I can try that after, or try Angular CLI's master locally (probably tomorrow).
@alan-agius4 Awesome, I wasn't aware of any of these flags. I'll give that a shot right now just to see if there's any changes. I'm not sure if SRI is on by default, or if we even need it to be honest.
Update: I tried two things. Using the default Nx build we use, and the regular Angular CLI directly to see if that would make any changes. Both result in the same
└ ❯ update/angular-12.2 ↑78 ❯ × ❯ ng build --configuration production --no-extract-licenses --no-subresource-integrity --verbose
✔ Browser application bundle generation complete.
An unhandled exception occurred: Maximum call stack size exceeded
See "/private/var/folders/n_/6gxtg46500l70fmptn_7mdph0000gn/T/ng-GANtCH/angular-errors.log" for further details.
So it doesn't appear to be related to webpack-subresource-integrity
and license-webpack-plugin
.
Fun fact tho, when I run it without --configuration production
it seems to work. Although it spits out a bunch of warnings because of the --verbose
flag and a message like this:
BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.
(Of which there may be more, haven't crawled through it all), so it might be to do with one of the production flags.
Ok so I played around with the "production" configuration, which breaks; but the regular configuration that does not break.
The difference seem to stem from "optimization": true
, which I could try to further dissect by making that more explicit in accordance with https://angular.io/guide/workspace-config#optimization-configuration, which I might try.
If I understand correctly, this part is also responsible for the dead-code elimination/tree-shaking process. Is this more on the Angular side, or is this handed off to Webpack? It might be somewhere in the interplay here.
@alan-agius4 @alexander-akait
Edit: Yeah attempted to further dissect the "optimization" part, and it does seem indeed to only relate to the scripts: true
part. The fonts or styles did not seem to have an effect in this particular case. I don't know enough about how the angular-optimization part of the compiler works exactly. Might have to dive into that to get an idea.
Also reproduces for me. And also for storybook. Described it here: https://github.com/storybookjs/storybook/issues/15957
@ihor-panasiuk95 run npm ls webpack
Using storybook with webpack5 we recently ended up getting "Maximum call stack size exceeded" when we try to build the storybook project.
It seems to be caused by the regex used for the match. I have seen it in two different spots. The other one was:
At first I thought it might be cause of a big chunk and source file but I tried to output "source" prior to the "source.match" and it seems to only contain:
/* module decorator */ module = __webpack_require__.hmd(module);\n
I'm not sure how to create a reproducable way for that issues however it vanishes when downgrading to webpack ~5.46.0 and whenever I upgrade back to ~5.47.0 the error reappears.