Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not seeing parsed or gzip statistics, stat size only #86

Closed
MrHavard opened this issue Jun 6, 2017 · 30 comments
Closed

Not seeing parsed or gzip statistics, stat size only #86

MrHavard opened this issue Jun 6, 2017 · 30 comments

Comments

@MrHavard
Copy link

MrHavard commented Jun 6, 2017

Issue description

I'm seeing stat size, but not parsed or gzip information. Is there something special that needs to be configured to see those for a production build? Would this need to be configured elsewhere in webpack stats configuration or within webpack-bundle-analyzer?

Technical info

  • Webpack Bundle Analyzer version: 2.8.2
  • Webpack version: 2.6.1
  • Node.js version: 6.10.1
  • npm/yarn version: 4.4.4
  • OS: Windows 10

Debug info

Using as a webpack plugin with the following settings:

new BundleAnalyzerPlugin({analyzerHost: 'localhost'});

What other Webpack plugins were used?
uglify, html-webpack-plugin, extract-text-webpack-plugin

@songxc
Copy link

songxc commented Jun 7, 2017

I met the same problem, look forward to a reply.

@valscion
Copy link
Member

valscion commented Jun 7, 2017

Hi, thanks for raising an issue! Seeing only stat sizes usually means that webpack-bundle-analyzer is not able to get access to your compiled bundles for some reason.

Do either of you get any error message logged to the console? For example, something like this?

Couldn't parse bundle asset "dist\version\1493729489528\js\app.js".
Analyzer will use module sizes from stats file

There could be a bug where webpack-bundle-analyzer is not able to parse your bundle assets, or it might not found the bundled JS files for some reason.

Are you able to create a stats.json with passing generateStatsFile: true setting to new BundleAnalyzerPlugin and then ZIP that and your compiled JS files over for me to check this out? If you don't want your source code to be posted in public, feel free to send the ZIP file over to me via email. My email address is visible in my GitHub profile.

@MrHavard
Copy link
Author

MrHavard commented Jun 7, 2017

I do not get any error or messages other than that Webpack Bundle Analyzer saved stats file and that it is started. Due to security I am unable to provide a stats file or source code.

I can tell you the general structure of bundled output:

dist
-- index.html
-- assets
--- js
---- app.js
---- app.js.map
--- css
---- app.css
---- app.css.map

Is there anything specifically I should be looking for in the stats file that might be missing or an indicator that something is wrong?

@valscion
Copy link
Member

valscion commented Jun 8, 2017

Could you try applying generateStatsFile: true to your new BundleAnalyzerPlugin setup and posting the entire file structure of your bundle directory?

Please follow these steps to generate a full tree of your bundle directory:

  1. Select your bundle output folder.
  2. Press Shift, right-click mouse, and select "Open command window here".
  3. Type tree /f /a | clip and press Enter.

You should now have the file tree in your clipboard. Could you paste it here?

@MrHavard
Copy link
Author

MrHavard commented Jun 8, 2017

dist
|   index.html
|   stats.json
|   
\---assets
    +---css
    |       app.3c5d4b10.css
    |       app.3c5d4b10.css.map
    |       
    +---fonts
    |       fontawesome-webfont.674f50d2.eot
    |       fontawesome-webfont.af7ae505.woff2
    |       fontawesome-webfont.b06871f2.ttf
    |       fontawesome-webfont.b8e85624.svg
    |       fontawesome-webfont.fee66e71.woff
    |       
    +---images
    |       fontawesome-webfont.912ec66d.svg
    |       
    \---js
            app.3c5d4b10.js
            app.3c5d4b10.js.map
            external.eaefbbfe.js
            external.eaefbbfe.js.map
            

@valscion
Copy link
Member

valscion commented Jun 8, 2017

Thanks!

Things should work OK, I wonder what's up with webpack-bundle-analyzer not showing parsed and gzip sizes...

Could you try adding statsOptions: { source: false } alongside the generateStatsFile: true option to new BundleAnalyzerPlugin setup and zip over the stats.json file here?

You could double-check that it doesn't contain your source codes before that, though — with statsOptions: { source: false } option, the stats.json should not contain any of your sources but it isn't a bad idea to doublecheck if you're not able to send the sources ☺️

Could you also show me what the value of output.path is in your webpack config file?

@MrHavard
Copy link
Author

MrHavard commented Jun 8, 2017

output: path.join(process.cwd(), 'dist'),

stats.zip

@valscion
Copy link
Member

valscion commented Jun 8, 2017

I am unfortunately unable to replicate this error without your bundled files. I tried creating a reproduction case and even ran it in a Windows 10 virtual machine (I'm developing on macOS), and it still works.

screen shot 2017-06-08 at 10 34 51

Could you try running webpack-bundle-analyzer via the CLI?

node .\node_modules\.bin\webpack-bundle-analyzer dist\stats.json

Does this still only give you the stat sizes?

@MrHavard
Copy link
Author

MrHavard commented Jun 8, 2017

There must be something wrong somewhere else in my configuration outside of the analyzer. If I attempt to run the CLI from a local install I get

C:\myco\workspaces\web\customer-ui\node_modules\.bin\webpack-bundle-analyzer:2
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
          ^^^^^^^
SyntaxError: missing ) after argument list
    at createScript (vm.js:56:10)
    at Object.runInThisContext (vm.js:97:10)
    at Module._compile (module.js:542:28)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.runMain (module.js:604:10)
    at run (bootstrap_node.js:393:7)
    at startup (bootstrap_node.js:150:9)

If I install the analyzer globally then the CLI works fine and I get all three stats correctly.

Running this instead from the local project works correctly as well:

node .\node_modules\webpack-bundle-analyzer\lib\bin\analyzer.js dist\stats.json

@valscion
Copy link
Member

valscion commented Jun 9, 2017

There must be something wrong somewhere else in my configuration outside of the analyzer. If I attempt to run the CLI from a local install I get

Ah yes, I think it is due to npm installing binaries on Windows wrapped in .cmd files, and I didn't know that. Instead of me asking you to call this:

node .\node_modules\.bin\webpack-bundle-analyzer dist\stats.json

...I should've asked you to try this instead:

.\node_modules\.bin\webpack-bundle-analyzer dist\stats.json

There seems to be lots of issues about this behavior when googling, and I even found one similar case in rimraf repository here: isaacs/rimraf#107 and isaacs gave a nice explanation of this case in here: dougludlow/ng2-bs3-modal#47

Does it work without a global installation of the analyzer if you try calling the node_modules\.bin\webpack-bundle-analyzer without first calling node?

@valscion
Copy link
Member

valscion commented Jun 9, 2017

Seeing as the global installation works, there might be some problems with how the plugin works on your machine. There might be some conflict with another plugin or config setting that I just haven't heard of before.

Are you able to modify the node_modules/webpack-bundle-analyzer/lib/BundleAnalyzerPlugin.js file and add a console.log to the second argument passed to viewer.startServer (the options object) and tell me what it outputs for you? Especially the this.getBundleDirFromCompiler() output is interesting, as if that is null or falsy, we won't ever even try to parse the compiled files and thus will never get to showing gzip nor parsed sizes.

Also have you at some point ever got a report that worked with an older version of the plugin before? Could you try the plugin with version 2.7.0 of webpack-bundle-analyzer?

@drcmda
Copy link

drcmda commented Jun 9, 2017

@valscion
I get the same when i switch WBA to new BundleAnalyzerPlugin({ analyzerMode: 'static' })and suddenly the only option left is stat. It served the other options fine in server mode.

@MrHavard
Copy link
Author

MrHavard commented Jun 9, 2017

bundleDir appears to be null:

{ 
  openBrowser: true,
  host: 'localhost',
  port: 8888,
  bundleDir: null,
  logger: Logger { activeLevels: Set { 'info', 'warn', 'error', 'silent' } },
  defaultSizes: 'parsed' 
}

UPDATE: I tried a few variations and it appears that regardless of whether I am running webpack-dev-server or generating a production build this.compiler.outputFileSystem.constructor.name is always going to be MemoryFileSystem resulting in bundleDir being null and not producing parsed or gzip stats.

@valscion
Copy link
Member

@drcmda could you open a separate issue for your problem?

@MrHavard thank you for the analysis! This is what I feared was happening. Would you be able to create a minimal reproduction repository for this issue? I'm not really sure why this is happening, but it would be amazing to be able to replicate it myself to fix it :)

@MrHavard
Copy link
Author

Sorry been too busy to get a repo together. Will try to do that soon.

@valscion
Copy link
Member

And for the time being, you can also work around this by downgrading to v2.7.0. We'd still like to fix this, though :)

@Ixonal
Copy link

Ixonal commented Jun 21, 2017

Just having this issue myself. Could bundleDir be set by a command line option?

I did notice that if I had my stat file placed into my dist folder and run webpack-bundle-analyzer off of that, it will display the other sizes correctly, so that could be a workaround.

@th0r
Copy link
Collaborator

th0r commented Jun 21, 2017

@Ixonal Type webpack-bundle-analyzer --help in the command line to see all the answers.

@Ixonal
Copy link

Ixonal commented Jun 21, 2017

derp... Sorry, should've noticed that earlier.

@th0r
Copy link
Collaborator

th0r commented Jun 21, 2017

@Ixonal No problem =)

@PengyuanZhao
Copy link

I can only see the stat size when running it with webpack dev server.

@th0r
Copy link
Collaborator

th0r commented Jun 21, 2017

@PengyuanZhao it's how it should be because webpack dev server don't save output bundles in the real filesystem and there is nothing to parse.

@warmhug
Copy link

warmhug commented Jun 30, 2017

I can only see the stat size when running it with webpack dev server.

@th0r How to solve it?

@valscion
Copy link
Member

@warmhug, to see gzip and parsed sizes, don't use webpack-dev-server

@th0r
Copy link
Collaborator

th0r commented Jun 30, 2017

@warmhug Or if it's not so hard, could you read my message right above yours?

@th0r
Copy link
Collaborator

th0r commented Jul 13, 2017

@MrHavard Were you able to find some time to create a reproduction repo?

@dottodot
Copy link

Think it's related this.

angular/angular-cli#7057

@dottodot
Copy link

dottodot commented Aug 4, 2017

I think this may have been a issue to @angular/cli as I'm now using 1.3.0-rc.5 and the problem seem to have gone away.

@axe312ger
Copy link

axe312ger commented Aug 14, 2017

Having the same problems, could it be that webpack-bundle-analyzer just ignores the output.path config? If it would follow it, it would perfectly find my file.

webpack-bundle-analyzer -s stat webpack-build-log.json

Couldn't parse bundle asset "/Users/.../project-root/app.js".
Analyzer will use module sizes from stats file.

Webpack Bundle Analyzer is started at http://127.0.0.1:8888
Use Ctrl+C to close it

It tries to load the app.js from the root directory, while output.path is set to resolve(__dirname, 'dist')

Edit: Okay reading helps, I can just pass it as parameter. But, still, I'd love this to be an automated parameter <3

@valscion
Copy link
Member

Edit: Okay reading helps, I can just pass it as parameter. But, still, I'd love this to be an automated parameter <3

It is as automated as the CLI can be :) as it infers the directory from where your stats are.

I think that this issue is too vague as there seems to be multiple causes for this case. I'll close this issue for now. Everyone's free to open new specific issues with a proper bug report, if you think you've faced a bug :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants