Could't analyze webpack bundle

[drcmda]

Issue description

I am getting this message in the end of the webpack emitts:

TypeError: Cannot read property 'raw' of undefined Could't find any javascript bundles in provided stats file

Technical info

• Webpack Bundle Analyzer version: 2.1.1
• Webpack version: 2.1.0-beta.27
• Node.js version: v7.2.0
• npm/yarn version: 3.10.5/0.17.9
• OS: Windows 10

Debug info

How do you use this module?

Plugin

If plugin, what options were provided?

None

What other Webpack plugins were used?

new webpack.LoaderOptionsPlugin({
    options: { worker: { output: { filename: "build/worker.js" } } } }),
new webpack.HotModuleReplacementPlugin(),
new webpack.NamedModulesPlugin(),
new BundleAnalyzerPlugin()

stats.zip

[th0r]

Technical info

What are the actual versions behind the latest?

[drcmda]

Added it :)

[th0r]

Is 2.1.1 the only version of analyzer you tried or it worked before?

[drcmda]

2.1.0 the same. I haven't known about it before.

[arialpew]

Same problem with :

{
    "webpack": "^2.2.0-rc.0",
    "webpack-bundle-analyzer": "^2.2.0"
}

[ganapativs]

Same issue (Could't find any javascript bundles in provided stats file).

"webpack": "2.1.0-beta.20", "webpack-bundle-analyzer": "^2.2.0"

[christianalfoni]

Yeah, same with Webpack 2.1.0-beta.28... maybe a change to stats file? Looking into it now

[christianalfoni]

Seems to be fixed here: https://github.com/gbakernet/webpack-bundle-analyzer/commit/b033c3ac7888d651686ac733fe7af92e54a18a5d

It worked on my end, though I have an issue with parsing bundles... so can not get gzip etc. stuff

[alifr]

I'm not getting the TypeError, but I have a similar issue concerning the "Couldn't parse bundle asset..." and not getting the gzip stats. All my modules are AMD as we recently switched from requireJS. "webpack": "^2.2.0-rc.0" "webpack-bundle-analyzer": "^2.2.0"

Amazing module by the way. I absolutely love using it.

[unsafecode]

Same issue with webpack@2.1.0-beta.22 and webpack-bundle-analyzer@2.2.0 (global)

[eshion]

Same issue: "webpack": "^1.13.3", "webpack-bundle-analyzer": "^2.1.1",

[alanrubin]

Experiencing the same issue here, the change proposed above fixed it. "webpack": "^1.12.14", "webpack-bundle-analyzer": "^2.2.0",

Maybe you could do the change and release it ?

[th0r]

Published v2.2.1 with the fix.

[th0r]

@christianalfoni @alifr Could you send me your bundles to try to fix these parsing problems?

[christianalfoni]

@th0r You only need the built bundles right? Not the source?

[th0r]

@christianalfoni yep, only problematic bundles

[christianalfoni]

Hm, how do I get the bundles to files? They are kept in memory it seems?

[th0r]

@christianalfoni are you analyzing dev bundle that is being served by webpack-dev-server?

[christianalfoni]

@th0r Jup, exactly :) I should just turn off devServer?

[th0r]

@christianalfoni well, in case of dev-server there are no physical bundles to parse - they're all locate in memory. Recommended way to use analyzer is to inspect your production bundles because in most cases module sizes there will differ a lot from dev version.

[christianalfoni]

Oh, wait... actually, the dev server is not running. I am running analyzer with production mode. So basically it is the same as when we build our production bundles, only that we add the analyzer plugin. Is it because we use the server config? Does it create the bundles when we do a static output instead?

[christianalfoni]

No, wait... of course, sorry... I was confused by our config. It is of course running webpack-dev-server. Here is the file with the issue, run with normal webpack :)

82a297b7ce067dbcc55c.js.zip

[frankleng]

ran into the same issue today. it worked wonderfully before, but have made a few code changes since then.

worst case I'll git bisect this. love the project @th0r!

[InSuperposition]

I'm having a similar issue, after initial install webpack-bundle-analyzer worked as expected. On second attempt I get:

Could't analyze webpack bundle:
TypeError: Cannot read property 'raw' of undefined
Could't find any javascript bundles in provided stats file

webpack: "^2.1.0-beta.27", webpack-bundle-analyzer: "^2.2.1", node: 4.5.0 OS X

I am NOT using the CommonChunks plugin

[matteoantoci]

I can confirm, I'm getting this error since I introduced the CommonsChunkPlugin:

Could't analyze webpack bundle:
TypeError: Cannot read property 'raw' of undefined
Could't find any javascript bundles in provided stats file

"webpack": "^1.14.0", "webpack-bundle-analyzer": "^2.2.1", "webpack-dev-server": "^1.16.2" node: 6.6.0 OS X

[Koslun]

Same error with default options & analyzerMode set to 'static':

Could't analyze webpack bundle:
TypeError: Cannot read property 'raw' of undefined
Could't find any javascript bundles in provided stats file

Some dependencies:

{
"awesome-typescript-loader": "2.2.4",
"postcss-loader": "^1.2.2",
"raw-loader": "~0.5.1",
"typescript": "2.0.10",

"webpack": "2.2.0",
"webpack-bundle-analyzer": "2.2.1",
"webpack-dev-middleware": "1.9.0",
"webpack-dev-server": "2.2.0",
}

The app itself is an angular app for what it's worth.

node: v6.9.1 OS: Ubuntu 16.04, OS X & Windows 10

It did work for us in december of 2016 but unsure when exactly it broke and why. We did change from using md5 hashing to just regular build hashes. But turning of hashes altogether at least does not seem to fix anything.

[valscion]

I have trouble trying to understand what I need to setup in order to replicate this issue.

The stats.zip file in the original issue seems to work splendidly. If this has something to do with the combo of the stats file plus the built files, I would need them both in order to debug this further.

It seems that @christianalfoni has an issue with the built file you uploaded. What's the stats.json file that accompanies that file?

The way I try to replicate it from the source of this repository is the following:

1. clone this repository somewhere
2. npm install
3. npm run build
4. Run ./lib/bin/analyzer.js /path/to/the/stats.json /path/to/output.path/

Without having the contents of the output.path available, I can only visualize the stat sizes, but not the gzip or minify sizes.

It shouldn't matter much whether this library is used as a webpack plugin or as a CLI, like in my replication steps.

[jovinbm]

@valscion I have a multi-compiler webpack setup with the DLLPlugin, DLLReferencePlugin, and CommonChunks Plugin. One particular entry point in my stack uses require.ensure about 4 times.

I've tried the following:

• Refrain from using the DLL plugins: Still get the same error.
• Refrain from using the CommonsChunk Plugin: Still get the same error.
• Refrain from both DLL and CommonsChunk Plugin: Still get the same error
• Keep DLL Plugin, CommonsChunk Plugin and just remove the entry point that uses require.ensure: No errors.

I've been commenting out this entry point whenever I wanted to analyze my build and It has worked every time. require.ensure might be one of the culprits.

"webpack": "^1.14.0",
"webpack-bundle-analyzer": "^2.2.1"

The error:

Could't analyze webpack bundle:
TypeError: Cannot read property 'raw' of undefined
Could't find any javascript bundles in provided stats file

[valscion]

It's strange, as we (in my company) are boasting CommonsChunkPlugin, too, and don't have any trouble. We also use require.ensure and those chunks show up correctly, too.

Have you tried to not use a multi-compiler webpack setup?

It seems that this error is potentially caused by a multitude of things. Most likely the line where the error is raised (TypeError: Cannot read property 'raw' of undefined) comes from here: https://github.com/th0r/webpack-bundle-analyzer/blob/a6dacbdd1b03c50feffadc14134c346c0f6d7178/src/analyzer.js#L90

For some reason, the parsedModuleSizes object might have got out of sync with the bundleStats.modules being looped through there.

I'm not 100% sure what the code does, but I could dig in if I'd have some scenario I could reproduce more easily.

@jovinbm are you able to generate a stats.json file and test run it through the webpack-bundle-analyzer CLI you've got installed?

./node_modules/.bin/webpack-bundle-analyzer path/to/my/stats.json

Does this cause the same error to be raised? What if you strip the sources from your stats.json file by generating it with a config looking like this?

new BundleAnalyzerPlugin({
  analyzerMode: 'disabled',
  generateStatsFile: true,
  statsOptions: { source: false }
})

If you run the generated stats.json file through the CLI, do you still see the same error, or not?

[matteoantoci]

I use CommonChunkPlugin, DllReferencePlugin and the promise-loader (pretty similar to require.ensure). I can confirm the issue can be reproduced when setting the analyzerMode to static.

Setting it to disabled the analyzer works correctly and it generates the json stats file.

[jovinbm]

@valscion. Thank you for the prompt response. I will try your suggestions later today and post back here.

[valscion]

@matteoantoci, were you able to reproduce this issue with the steps I outlined?

1. Generate the stats.json file by running the plugin like this:

   new BundleAnalyzerPlugin({
     analyzerMode: 'disabled',
     generateStatsFile: true,
     // Excludes module sources from stats file so there won't be any sensitive data
     statsOptions: { source: false }
   })

2. Run the generated stats.json file (it will be in your bundle output directory) through the CLI:

   ./node_modules/.bin/webpack-bundle-analyzer path/to/my/stats.json

If these steps worked, try without the statsOptions setting. Do you then get the error?

If you don't get the error even then, try to pass the output directory (dictated by webpack config output.path value) to the CLI, too:

./node_modules/.bin/webpack-bundle-analyzer path/to/my/stats.json path/to/output/directory

Do you now get the error? If not, try switching the CLI reported mode to static:

./node_modules/.bin/webpack-bundle-analyzer \
  path/to/my/stats.json \
  path/to/output/directory --mode static

Do you now get the error?

[matteoantoci]

Here I am. Yes I tried with the above options. The stats.json is generated but then, when I try to parse it through webpack-bundle-analyzer, it rises the same exception.

Here is the generated json: stats.json.zip

[valscion]

I'm sorry but the stats.json isn't enough for me to replicate it:

If the stats.json is in the same directory as the bundled sources, the CLI will look into that directory for the original assets. That's why you're able to replicate it on your machine, as you have the bundled sources, but I am not.

./node_modules/.bin/webpack-bundle-analyzer path/to/my/stats.json

With the above command, the CLI deducts that bundle folder is path/to/my and searches it for the bundled sources. In your case, it works, but in my case, it doesn't, so I am not able to reproduce your error.

Are you ok with sending me the bundled codes, or are you able to create a public reproduction repository somewhere I could hack on?

[matteoantoci]

Sure, here you are: Archive.zip

[valscion]

Yess, I'm able to reproduce this. I'll look into it, thanks @matteoantoci :+1:

[valscion]

Ok, #42 would allow you to generate the report but it won't still be able to show you the information the plugin fails to collect for some reason.

If you want to give it a shot, and maybe test out what parts of your code might cause the issue, there's hopefully good instructions in CONTRIBUTING.md on how to test-drive a development version of this plugin.

Just run it from my fork instead:

git clone git://github.com/valscion/webpack-bundle-analyzer.git
git checkout quickfix-29

[matteoantoci]

@valscion I confirm it works, I think that should be a nice fix. BTW, the problematic modules are the one marked as "ignored", did I understand correctly?

[valscion]

I confirm it works, I think that should be a nice fix

:tada: Yess, great to hear that!

BTW, the problematic modules are the one marked as "ignored", did I understand correctly?

If you mean the ones missing gzip sizes and parsed sizes then yes, those were problematic for some reason.

[valscion]

If others that had issues could also try #42 with the instructions I posted earlier: https://github.com/th0r/webpack-bundle-analyzer/issues/29#issuecomment-276687904, that would be super valuable ☺️

[Koslun]

@valscion Can also confirm that #42 allows me to successfully produce the graph, with one problematic chunk seemingly ignored but visible.

The node_modules imports in the problematic chunk are:

{
"@swimlane/ngx-datatable": "^5.0.0",
"ammap3": "amcharts/ammap3",
"d3": "4.4.0",
"ng2d3": "~2.0.0",
"lodash": "^4.16.1",
}

Where only certain methods of lodash are imported:

const map = require('lodash/map');
const find = require('lodash/find');
const cloneDeep = require('lodash/cloneDeep');
const findIndex = require('lodash/findIndex');
const forEach = require('lodash/forEach');
const invert = require('lodash/invert');
const pullAt = require('lodash/pullAt');
const reduce = require('lodash/reduce');
const remove = require('lodash/remove');
const reverse = require('lodash/reverse');
const sortBy = require('lodash/sortBy');
const unionBy = require('lodash/unionBy');

Validated imports of chunk using https://chrisbateman.github.io/webpack-visualizer/.

Can't think of anything else particular about that chunk other than that it is by far the biggest chunk made for admins, weighing in at about a full 1 MB, without gzip (95% are those dependencies).

[valscion]

Yess, great to hear that #42 works for you, too, @Koslun! ☺️

I have no knowledge why these specific cases would cause issues. In our application, we also use lodash and import specific modules from there so I doubt it's the culprit.

It would be superduper awesome if you're able to bisect by commenting out some imports until you reach a place where commenting out a small chunk "fixes" the parsed and gzip sizes while adding it back in breaks it. That way there would at least be some hint as to why this breaks 😅

The reason why Stat sizes still work is that they are fetched from the webpack stats object directly. The parsed and gzip sizes are calculated by reading the actual compiled output and making a link back to the stats object from there.

As you probably can figure it out, figuring out the module from the compiled, minified code might get a bit too hairy at some points in which the analyzer trips over.

The reason why webpack-visualizer works without trouble is that it only reads the stats object and doesn't try to do the complicated link back from minified sources to the module in webpack stats object.

[Koslun]

It would be superduper awesome if you're able to bisect by commenting out some imports until you reach a place where commenting out a small chunk "fixes" the parsed and gzip sizes while adding it back in breaks it. That way there would at least be some hint as to why this breaks 😅

Ok. I'll try to get around to it this weekend but I might not end up doing it until sometime next week.

The reason why webpack-visualizer works without trouble is that it only reads the stats object and doesn't try to do the complicated link back from minified sources to the module in webpack stats object.

Makes sense and this library doing all that work is definitely very valuable and the biggest reason why I normally only use this library to analyse the bundles.

[valscion]

Ok. I'll try to get around to it this weekend but I might not end up doing it until sometime next week.

No worries :). I've got some ideas on how to implement a thorough test suite for this part of the code but I'm waiting for @th0r to get some time to discuss future improvements ☺️

[valscion]

Ok, seems like this issue stems not from the modules inside the bundle, but how webpack has bundled the modules together.

Normally, a chunk starts with something like this:

webpackJsonp_adhaghasd([0,2],[ /* modules here */ ])

..or like this:

!function(e){/* webpack bootstrap */}([ /* modules here */])

But at least in @matteoantoci's case, the troublesome chunk starts like this:

webpackJsonplmn_ui_obe__name_Init([0],Array(104).concat([ /* modules here */]))

This case is not handled by the utility parsing the module object back from the compiled source using AST parser, parseUtils.js

It would be awesome if people having trouble with this issue could make sure whether the failing bundles have this sort of Array(<minimum module ID>).concat( structure as their very first thing in the file.

That module template comes from this line in the webpack source code: https://github.com/webpack/webpack/blob/v1.14.0/lib/Template.js#L91

It seems like this is some sort of an optimization inside webpack that allows the modules to be listed in chunks without having to specify hundreds of "empty" elements before.

[valscion]

Please go test out #44 for a proper fix! It should work for the TypeError: Cannot read property 'raw' of undefined case.

If you still get that error with your bundle, I'm gonna need your compiled sources to check this out. I might be able to figure this out with just first 1000 characters of your bundles if you can't publish your entire compiled code.

[matteoantoci]

@valscion tested it and it worked perfectly!! =)

[Koslun]

@valscion also tested #44 now and it worked perfectly for me too :)

[InSuperposition]

Its working for me, Thank you!

[frankleng]

44 worked for me too!