django-webpack / webpack-bundle-tracker Goto Github PK

When you run webpack 2 to split react routes code or make lazy loading, the webpack-stats.json does not match to files 0.js, 1.js and etc.

A sample for react lazy loading is here: https://webpack.js.org/guides/lazy-load-react/

and for react routes: https://brotzky.co/blog/code-splitting-react-router-webpack-2/

Issue description

In local build, webpack-stats is good, it looks like:

...
"assets": 
    "offers-928c50a.js": {
      "name": "offers-928c50a.js",
      "path": "[hidden]/static/bundles/offers-928c50a.js",
      "publicPath": "/static/bundles/offers-928c50a.js"
    },
...
"chunks": {
    "offers": [
      "offers-928c50a.js"
    ],
}

But in ci build, it looks like:

... // assets section missing
"chunks": {
    "offers": [
      {
        "name": "offers-928c50a.js",
        "publicPath": "/static/bundles/offers-928c50a.js",
        "path": "[hidden]/static/bundles/offers-928c50a.js"
      }
    ],
}

Then in ci tests will emit many weird errors: TypeError: expected string or bytes-like object.
My question is what can make that difference?

Technical info

 Binaries:
    Node: 14.17.3 - /usr/local/bin/node
    Yarn: 1.22.21 - /usr/local/bin/yarn
    npm: 6.14.13 - /usr/local/bin/npm
  npmPackages:
    uglifyjs-webpack-plugin: ^2.2.0 => 2.2.0 
    webpack: 5.58.0 => 5.58.0 
    webpack-bundle-tracker: 2.0.1 => 2.0.1 
    webpack-cli: 4.9.0 => 4.9.0 

Optional chaining is not supported in Node.js version 12, so this code has broken declared compatibility.

When the compression plugin is told to remove original asset (for example for use with nginx gzip_static + gunzip options) the bundle tracker only saves the .gz version keys in assets dictionary and the chunk assets list is empty ("mychunk": []).

Expected behavior would be that assets continues listing the deleted uncompressed files and that chunks reference the assets without .gz suffix.

#17 (comment)

I am using webpack-bundle-tracker in conjunction with django-webpack-loader. My folder structure looks like:

project/
    django_project/
    react_project/

I had my bundle tracker configured to ouput the stats file outside the package itself, like: ../django_project/webpack-stats.json. The reason for doing this is that I wanted to include the webpack-stats.json in my Dockerfile which lives inside django_project.

I have updated a number of dependencies today, including webpack-bundle-tracker to 1.0.0-alpha.1. I noticed that the stats file is no longer getting output outside the react_project folder, no matter how many double dots (..) I prepend in the bundle tracker filename.

• Is this intentional?
• Is this a decision of this package? (could also be something from another package I updated)
• Any elegant way to overcome this?

Thanks!

Currently the webpack-stats.json only has entries for .css and .js files.

What about font and image files that are outputed by the file-loader ? How can I make it so that they are included in the .json too?

It appears that if there already is a webpack-stats.json file built by yarn start, then running npm start returns the following error:

Error: EACCES: permission denied, open 'webpack-stats.json'
    at Object.openSync (node:fs:495:3)
    at Object.writeFileSync (node:fs:1519:35)
    at Plugin.writeOutput (/app/node_modules/webpack-bundle-tracker/lib/index.js:124:6)
    at compile (/app/node_modules/webpack-bundle-tracker/lib/index.js:58:10)
    at SyncHook.eval [as call] (eval at create (/app/node_modules/tapable/lib/HookCodeFactory.js:19:10), <anonymous>:7:1)
    at SyncHook.lazyCompileHook (/app/node_modules/tapable/lib/Hook.js:154:20)
    at /app/node_modules/webpack/lib/Compiler.js:665:23
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/app/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:6:1)
    at AsyncSeriesHook.lazyCompileHook (/app/node_modules/tapable/lib/Hook.js:154:20)
    at Compiler.compile (/app/node_modules/webpack/lib/Compiler.js:662:28)
    at /app/node_modules/webpack/lib/Watching.js:77:18
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/app/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:24:1)
    at AsyncSeriesHook.lazyCompileHook (/app/node_modules/tapable/lib/Hook.js:154:20)
    at Watching._go (/app/node_modules/webpack/lib/Watching.js:41:32)
    at /app/node_modules/webpack/lib/Watching.js:33:9
    at Compiler.readRecords (/app/node_modules/webpack/lib/Compiler.js:529:11)

Can't this behavior be avoided?

Gzipped bundles compressed with webpack-compressor-plugin are not being tracked and, therefore, not available in the json output.

This warning is given when building webpack 4 configs using this plugin.

(node:9264) DeprecationWarning: Tapable.plugin is deprecated. Use new API on .hooks instead

Hi, this is a great project, and great write-up about all of this!

Just ran into some funkiness: when I have a webpack.config.js like:

  plugins: [
      new webpack.optimize.CommonsChunkPlugin("commons.chunk.[hash].js"),
      new BundleTracker({path: BUILD_ROOT, filename: './webpack-stats.json'}),
  ],

I get output in webpack-stats.json like:

    "commons.chunk.[hash].js": [
      {
        "name": "commons.chunk.3c5952bfdfd9e5d8fca5.js",
        "publicPath": "_\/static\/js\/commons.chunk.3c5952bfdfd9e5d8fca5.js",
        "path": "\/Users\/peterconerly\/src\/picmonkey\/build\/website\/js\/commons.chunk.3c5952bfdfd9e5d8fca5.js"
      }
    ]

It's kind of weird, it feels like it should be omitting the [hash] in the key. And probably the .js too, to be consistent with how pages are generated.

I'm using your django plugin, so that means that my render_bundle ends up looking like:

{% load render_bundle from webpack_loader %}

{% render_bundle 'commons.chunk.[hash].js' %}
{% render_bundle 'index_module' %}

So everything works, it just looks kind of odd and feels like it might be an oversight.

After npm installation of the current version (0.3.0), npm gives the following warning after running npm audit.

Some vulnerabilities require your attention to resolve:
Low: Prototype Pollution
Package: deep-extend
Patched in: >=0.5.1
Dependency of: webpack-bundle-tracker
More info: https://nodesecurity.io/advisories/612

I think that the version of deep-extend needs to be upgraded from 0.4.1 and repackaged. Manually upgrading deep-extend didn't seem to cause any problems, but I only have a small project and didn't test.

    compiler.hooks.compile.tap(this.name, this._handleCompile.bind(this, compiler));
                   ^
TypeError: Cannot read property 'compile' of undefined

Using wepack 2.7 (I know it is ancient, but did not have the time to upgrade).

This issue tracks the implementation of the Jazzband guidelines for the project webpack-bundle-tracker

It was initiated by @owais who was automatically assigned in addition to the Jazzband roadies.

See the TODO list below for the generally required tasks, but feel free to update it in case the project requires it.

Feel free to ping a Jazzband roadie if you have any question.

TODOs

• Fix all links in the docs (and README file etc) from old to new repo
• Add the Jazzband badge to the README file
• Add the Jazzband contributing guideline to the CONTRIBUTING.md or CONTRIBUTING.rst file
• Check if continuous testing works (e.g. Travis CI, CircleCI, AppVeyor, etc)
• Check if test coverage services work (e.g. Coveralls, Codecov, etc)
• Add jazzband account to PyPI project as maintainer role (e.g. URL: https://pypi.org/manage/project/webpack-bundle-tracker/collaboration/)
• Add jazzband-bot as maintainer to the Read the Docs project (e.g. URL: https://readthedocs.org/dashboard/webpack-bundle-tracker/users/)
• Add incoming GitHub webhook integration to Read the Docs project (e.g. URL: https://readthedocs.org/dashboard/webpack-bundle-tracker/integrations/)
• Fix project URL in GitHub project description
• Review project if other services are used and port them to Jazzband
• Decide who is project lead for the project (if at all)
• Set up CI for Jazzband project releases if needed and open ticket if yes

Project details

What is the reasoning behind tracking path and filename separately? It's prone to errors, as filename is always a relative path even if it begins with a slash, which means that, for example, filename: "/var/www/webpack-stats.json" would be written into /var/www/var/www/webpack-stats.json which is extremely counter-intuitive.

Would it be possible to allow different formatting options for the startTime and endTime values? I find myself needing to check them while experimenting with webpack settings but unix timestamps aren't really that user-friendly. An output of HH:mm:ss would be more helpful.

(Though I'm not sure if toLocaleTimeString() would be best-suited or if it should be the only way to display the datetimes in a more human-readable format. It'd easily work fine locally but might require more fiddling when used on servers or in containers etc.)

Currently we have tests but they aren't running in CI. We do have a travis.yml file but I'm not sure if it's being run somewhere.

$ cat >webpack.config.js <<EOF
const BundleTracker = require("webpack-bundle-tracker");
module.exports = {
  plugins: [new BundleTracker({ relativePath: true })],
};
EOF
$ touch src.js
$ npm i webpack webpack-bundle-tracker webpack-cli
…
+ [email protected]
+ [email protected]
+ [email protected]
added 147 packages from 168 contributors and audited 147 packages in 5.273s
…
$ npx webpack
[webpack-cli] TypeError [ERR_INVALID_ARG_TYPE]: The "to" argument must be of type string. Received undefined
    at validateString (internal/validators.js:124:11)
    at Object.relative (path.js:1054:5)
    at /tmp/test/node_modules/webpack-bundle-tracker/lib/index.js:138:30
    at /tmp/test/node_modules/lodash.foreach/index.js:221:11
    at baseForOwn (/tmp/test/node_modules/lodash.foreach/index.js:153:20)
    at /tmp/test/node_modules/lodash.foreach/index.js:190:14
    at forEach (/tmp/test/node_modules/lodash.foreach/index.js:290:10)
    at BundleTrackerPlugin._handleDone (/tmp/test/node_modules/webpack-bundle-tracker/lib/index.js:123:5)
    at Hook.eval [as callAsync] (eval at create (/tmp/test/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:9:1)
    at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (/tmp/test/node_modules/tapable/lib/Hook.js:18:14) {
  code: 'ERR_INVALID_ARG_TYPE'
}

At webpack-bundle-tracker/lib/index.js:138, the file object is a SizeOnlySource whose only property is _size, so fileInfo.path is undefined.

Like "@types/mkdirp"

In the current code, the plugin constructor name is a generic name Plugin. The following case is why this is a concern.

We have a base webpack.config.js shared across all projects in our company. Each project will use webpack-merge to assign project specific customizations. A BundleTracker plugin is enabled in the base config file, however in one project we need to disable it. We use the webpack-merge's customizeArray feature to do this:

// const baseConfig = require('/path/to/base.config.js')
const baseConfig = {
  ...
  plugins: [
    new BundleTracker({ path: BUILD_DIR, filename: '../webpack-stats.json' }),
    new webpack.ProgressPlugin(),
    new MiniCssExtractPlugin({...}),
    new webpack.HotModuleReplacementPlugin(),
    new VueLoaderPlugin(),
  ]
  ...
}

module.exports = merge({
  customizeArray(a, b, key) {
    if (key === 'plugins') {
      // filter out bundle tracker plugin
      // XXX here we have no reliable way to identify the bundle tracker plugin
      return a.filter(p => p.constructor.name !== 'Plugin')
    }
    // fallback to default merging
    return undefined
  }
})(baseConfig, {...})

We're lucky that other plugins we enabled in base config all have reasonable names, for example:

• webpack.ProgressPlugin: ProgressPlugin
• MiniCssExtractPlugin: MiniCssExtractPlugin
• webpack.HotModuleReplacementPlugin: HotModuleReplacementPlugin
• VueLoaderPlugin: VueLoaderPlugin

so this approach works for us now. But I think it's not a good idea to write such code. On one hand, the reader won't understand why this code filters out the bundle tracker plugin, on the other hand, if any plugin we would use in the future also use Plugin as the name, it will be filtered out unexpectedly (in which case we will also report an issue to that project 😃 ).

Alpha.1 version returns assets as array:

"chunks": {
      "manage":[
         "js/vendors.js",
         "js/ui.js",
         "js/manage.js"
      ]
}

Is it intentional? It's against the given example. The valid output (according to 0.4) is just last entry, or rather it's value in assets:

"assets": {
      "js/manage.js": {
         "name":"js/manage.js",
         "path":"/home/user/dev/proj/dist/js/manage.js",
         "publicPath":"http://localhost:9090/js/manage.js"
      },
}

Previously was:

"chunks": {
      "manage":[
         {
            "name":"js/manage.js",
            "publicPath":"http://localhost:9090/js/manage.js",
            "path":"/home/user/dev/proj/dist/js/manage.js"
         }
      ],
}

For example i have

"chunks":{
      "home":[
         "vendors-node_modules_mini-css-extract-plugin_dist_hmr_hotModuleReplacement_js-node_modules_we-a0114e-f096b527166df6583ac8.bundle.js",
         "assets_custom-libs_semantic_parts_container_css-assets_custom-libs_semantic_parts_grid_css-as-b1ee4e.css",
         "home.css",
         "home-f096b527166df6583ac8.bundle.js"
      ]
}

I need

"chunks":{
      "home":[
         "e4e24724b5fcfe64adb9.woff2",
         "vendors-node_modules_mini-css-extract-plugin_dist_hmr_hotModuleReplacement_js-node_modules_we-a0114e-f096b527166df6583ac8.bundle.js",
         "assets_custom-libs_semantic_parts_container_css-assets_custom-libs_semantic_parts_grid_css-as-b1ee4e.css",
         "home.css",
         "home-f096b527166df6583ac8.bundle.js"
      ]
}

Is there a way to do this ? My fonts have changes time to time and name is dynamic. I need to get a relation bundle <-> fonts.

It seems that setting the path option in the BundleTracker options no longer has an effect. I think the issue was introduced in this commit. Regardless of what the path option is set to, the stats file is rooted in the cwd.

It's possible to work around the issue by specifying the full file path in the filename option.

I'm using webpack v 1.13.1 transpiling TypeScript and have webpack-bundle-tracker 0.0.93 which outputs webpack-stats.json such as the following:

{"status":"error","message":"(3,21): error TS2503: Cannot find namespace 'moment'.","publicPath":"/website/js/"}

django-webpack-loader is looking for a key 'error' which isn't present in this output and therefore the page throws a Python KeyError.

I'm on 3.0. Error log:

[webpack-cli] Failed to load '/webapp/webpack.config.js' config
[webpack-cli] Error [ERR_REQUIRE_ESM]: require() of ES Module /webapp/node_modules/strip-ansi/index.js from /webapp/node_modules/webpack-bundle-tracker/lib/index.js not supported.
Instead change the require of /webapp/node_modules/strip-ansi/index.js in /webapp/node_modules/webpack-bundle-tracker/lib/index.js to a dynamic import() which is available in all CommonJS modules.
    at Object.<anonymous> (/webapp/node_modules/webpack-bundle-tracker/lib/index.js:23:19)
    at Object.<anonymous> (/webapp/webpack.config.js:5:23)
    at async WebpackCLI.tryRequireThenImport (/webapp/node_modules/webpack-cli/lib/webpack-cli.js:232:34)
    at async loadConfigByPath (/webapp/node_modules/webpack-cli/lib/webpack-cli.js:1406:27)
    at async WebpackCLI.loadConfig (/webapp/node_modules/webpack-cli/lib/webpack-cli.js:1515:38)
    at async WebpackCLI.createCompiler (/webapp/node_modules/webpack-cli/lib/webpack-cli.js:1781:22)
    at async WebpackCLI.runWebpack (/webapp/node_modules/webpack-cli/lib/webpack-cli.js:1877:20)
    at async Command.<anonymous> (/webapp/node_modules/webpack-cli/lib/webpack-cli.js:944:21)
    at async Command.parseAsync (/webapp/node_modules/webpack-cli/node_modules/commander/lib/command.js:935:5)
    at async Command.<anonymous> (/webapp/node_modules/webpack-cli/lib/webpack-cli.js:1356:13)
    at async Command.parseAsync (/webapp/node_modules/webpack-cli/node_modules/commander/lib/command.js:935:5)
    at async WebpackCLI.run (/webapp/node_modules/webpack-cli/lib/webpack-cli.js:1360:9)
    at async runCLI (/webapp/node_modules/webpack-cli/lib/bootstrap.js:9:9) {
  code: 'ERR_REQUIRE_ESM'

Running npm audit (with npm 6) for webpack-bundle-tracker v0.3.0 shows it has a vulnerability caused by the deep-extend package: Would be great to update deep-extend and fix the vulnerability.

Webpack 4 removes the CommonsChunkPlugin and lets Webpack itself decide how to do code splitting (using the splitChunks and cacheGroups settings). This results in combined chunks as Webpack sees fit, possibly (entrypoints pageA and pageB result in three chunks: pageA + pageB + pageA~pageB).

As we no longer know which chunks to include for all code required for a specific entrypoint, we really should just be able pass in the entrypoints to any downstream tool such as django-webpack-loader.

Therefore, this plugin should ideally start exposing the entryPoint/chunk associations, similar to webpack --profile:

"entrypoints": { "Homepage": { "chunks": [ 0, 1, "Homepage" ], "assets": [ "0-de629161af8ff152d740.js", "1-de629161af8ff152d740.js", "Homepage-de629161af8ff152d740.js" ] },

django-webpack-loader can then just be instructed to {% render_bundle "Homepage" %} and load the three chunks 0, 1 and Home.

Refs django-webpack/django-webpack-loader#157.

Hello,

I followed the rather simple tutorial here https://owais.lone.pw/blog/webpack-plus-reactjs-and-django/ (as referred to in https://github.com/owais/django-webpack-loader). I'm using version 1.0.0-alpha.1

However, my stats file always ended up corrupt (stuck on status: "compile") when building using webpack --watch without error. When building without the --watch argument, I got the error below.

Error: EEXIST: file already exists, mkdir '/home/tso/Projects/bike/client/build'
    at Object.fs.mkdirSync (fs.js:885:18)
    at BundleTrackerPlugin._writeOutput (/home/tso/Projects/bike/client/node_modules/webpack-bundle-tracker/lib/index.js:79:8)
    at BundleTrackerPlugin._handleDone (/home/tso/Projects/bike/client/node_modules/webpack-bundle-tracker/lib/index.js:154:10)
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/home/tso/Projects/bike/client/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:9:1)
    at AsyncSeriesHook.lazyCompileHook (/home/tso/Projects/bike/client/node_modules/tapable/lib/Hook.js:154:20)
    at emitRecords.err (/home/tso/Projects/bike/client/node_modules/webpack/lib/Compiler.js:304:22)
    at Compiler.emitRecords (/home/tso/Projects/bike/client/node_modules/webpack/lib/Compiler.js:499:39)
    at emitAssets.err (/home/tso/Projects/bike/client/node_modules/webpack/lib/Compiler.js:298:10)
    at hooks.afterEmit.callAsync.err (/home/tso/Projects/bike/client/node_modules/webpack/lib/Compiler.js:485:14)
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/home/tso/Projects/bike/client/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:6:1)
    at AsyncSeriesHook.lazyCompileHook (/home/tso/Projects/bike/client/node_modules/tapable/lib/Hook.js:154:20)
    at asyncLib.forEachLimit.err (/home/tso/Projects/bike/client/node_modules/webpack/lib/Compiler.js:482:27)
    at /home/tso/Projects/bike/client/node_modules/neo-async/async.js:2818:7
    at done (/home/tso/Projects/bike/client/node_modules/neo-async/async.js:3522:9)
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/home/tso/Projects/bike/client/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:6:1)
    at AsyncSeriesHook.lazyCompileHook (/home/tso/Projects/bike/client/node_modules/tapable/lib/Hook.js:154:20)
    at outputFileSystem.writeFile.err (/home/tso/Projects/bike/client/node_modules/webpack/lib/Compiler.js:464:33)
    at /home/tso/Projects/bike/client/node_modules/graceful-fs/graceful-fs.js:61:14

My config:

const BundleTracker = require('webpack-bundle-tracker');
const path = require('path');

module.exports = {
    context: __dirname,
    entry: {
        app: ['./src/app.js']
    },
    output: {
        path: path.resolve('./build/'),
        filename: '[name]-[hash].js'
    },
    module: {
        rules: [
            {
                test: /\.js$/,
                exclude: /node_modules/,
                loader: 'babel-loader'
            },
            {
                test: /\.jsx$/,
                exclude: /node_modules/,
                loader: 'babel-loader'
            },
        ]
    },
    plugins: [
        new BundleTracker({
            // filename: './build/webpack-stats.json',
            // path: __dirname,

            filename: './webpack-stats.json',
            })
    ]
};

and my project structure

I googled and found two other cases and my setup is identical (no answer on either):
https://www.reddit.com/r/webpack/comments/hs94is/webpack_bundle_tracker_not_working/
https://stackoverflow.com/questions/62935574/webpack-bundle-tracker-not-working-error-eexist-file-already-exists-mkdir

I managed to monkey patch it by skipping the recreation of the folder if it already exists in lib/index:79. Now the code runs and the stats file is populated as expected.

if (!fs.existsSync(this.outputTrackerDir)) {
  fs.mkdirSync(this.outputTrackerDir, {recursive: true, mode: 0o755});
}

Any ideas as to why? -
Best regards

I'm trying to make use of webpack-bundle-tracker with a typescript configuration for webpack.
It seems typescript is not happy, because it spits out the message mentioned above and exists with a non-zero exit code.

I assume webpack-bundle-tracker needs to ship a type definition file for it to be happy.

According to my npm outdated the @latest of webpack-bundle-tracker is 0.4.2-beta.

I would like to upgrade because of issue #27 and #33, but I assume that the beta version is not ready for production, so I'm using version 0.3

Hi noticed all the tests are failing right now. Would you accept a PR moving them to github actions? If so, I could work on it if you'd like.

1.0.0-alpha.1 is in a strange state, and multiple solutions online to new issues are to just lock to 0.4.3.

Would it be possible to publish over the alpha release so that the stable 0.4.3 takes priority? Perhaps publish 0.4.3 as 1.0.1 or something?

If I change back to 0.4.3, it works fine.

const webpack = require('webpack');
const BundleTracker = require('webpack-bundle-tracker');

const config = require('./base.js');

// Use webpack dev server
config.mode = 'development';

config.devServer = {
    disableHostCheck: true,
    contentBase: '../assets/bundles/',
    compress: true,
    publicPath: 'http://0.0.0.0:3000/assets/bundles/',
    port: 3000,
    headers: {
            'Access-Control-Allow-Origin': '*'}}

config.plugins = config.plugins.concat([
  new BundleTracker({filename: 'webpack-stats.json'})]);

module.exports = config;

If you compile webpack bundles on one machine (like some CI) then deploy the application in production in a different directory, webpack-bundle-tracker can't read files. The reason for this is the bundles contains absolute paths, which may be different during runtime than when bundles were created.

This is a common case with CI environments and when target machines aren't powerful enough.

I've found that the ordering of keys is not guaranteed when outputting the stats file, and this doesn't work well with storing the JSON file in a version control system (i.e., git) since the file can change with subsequent runs of building.

This SO post has several solutions for ensuring the order, such as sorting things before calling JSON.stringify or using a 3rd party library, json-stable-stringify.

Is this something you'd support adding?

I am trying to include a directory tree in my bundle by adding

// this will import everything inside the static directory into the bundle
// http://stackoverflow.com/questions/27639005/how-to-copy-static-files-to-build-directory-with-webpack
require.context("./static/", true, /^.*/);

to the entry point main.js.

However these files (images) are not in the webpack-stats.json, even though they are successfully included in the bundle.

Am I missing something?

BTW this is used for a Django setup with https://github.com/owais/django-webpack-loader where I would like to include all images with {% webpack_static 'img/logo.png' %} so that I can set an infinite expiry date on all static resources in the webserver.

This is how the webpack-stats.json looks like:

{
  "status": "done",
  "chunks": {
    "main": [
      {
        "name": "main-8c8d3a3fe3a2a9478630.js",
        "path": "/Users/mario/Projects/getmyski/assets/dist/main-8c8d3a3fe3a2a9478630.js"
      },
      {
        "name": "main-8c8d3a3fe3a2a9478630.css",
        "path": "/Users/mario/Projects/getmyski/assets/dist/main-8c8d3a3fe3a2a9478630.css"
      },
      {
        "name": "main-8c8d3a3fe3a2a9478630.js.map",
        "path": "/Users/mario/Projects/getmyski/assets/dist/main-8c8d3a3fe3a2a9478630.js.map"
      },
      {
        "name": "main-8c8d3a3fe3a2a9478630.css.map",
        "path": "/Users/mario/Projects/getmyski/assets/dist/main-8c8d3a3fe3a2a9478630.css.map"
      }
    ]
  }
}

I am trying to access the name of one bundle in another bundle, and thought the stats file might be used for that.

The problem however, is that the stats file is only written to dist, so when requiring/importing it in one of my bundles, webpack crashes:

Module not found: Error: Can't resolve './stats.json'

Any idea how this can be fixed? Perhaps only read the file runtme somehow?

The django-webpack-loader package is already using in the 1.0.0 version (django-webpack/django-webpack-loader#269). What does this package need for a stable release? How can I help?

I have a question / feature request.

Is it possible to have the webpack-stats.json relative path instead of the full path?

I am sharing my project with other developers, and not all of them have NPM installed. So I want to have the lastest version of the bundle in my git repository.
Is there a good way to do that?

When using the deletefilesafterupload from @sentry/webpack-plugin with webpack-bundle-tracker, webpack throws an error of Error: ENOENT: no such file or directory, open 'path/to/file.map'

I assume this has to do with how generated files are handled/passed from one plugin to the next, so when the Sentry plugin removes them, that throws a wrench in things.

One option would also be to add an ignore option.

[webpack-cli] Error: ENOENT: no such file or directory, open '/project/path/build/js/user_settings.de3c34eb.js.map'
    at Object.openSync (node:fs:601:3)
    at Object.readFileSync (node:fs:469:35)
    at getSource (/project/path/node_modules/webpack-bundle-tracker/lib/index.js:31:13)
    at /project/path/node_modules/webpack-bundle-tracker/lib/index.js:180:53
    at /project/path/node_modules/lodash.foreach/index.js:221:11
    ...

We're using a configuration like

optimization: {
    splitChunks: {
      automaticNameDelimiter: '.',
      cacheGroups: {
        shared: {
          name: 'shared',
          chunks: 'initial',
          minChunks: 2,
        },
      },
      name: true,
    },
    runtimeChunk: {
      name: 'shared',
    },
}

which has Webpack hoist shared modules and the Webpack runtime itself into a shared chunk.
In our HTML (Django templates really) we guarantee that the shared chunk appears first on every page, so everything works.

With WBT 0.x, this appeared in the chunks output e.g.

    "shared": [
      {
        "name": "6726b09177234a35303e/shared.js",
        "publicPath": "/static/webpack-bundles/6726b09177234a35303e/shared.js",
        "path": ".../static/webpack-bundles/6726b09177234a35303e/shared.js"
      }
    ],

but with WBT 1.0, it's no longer shown separately in chunks, but is included in each chunk's asset list separately, e.g.

    "dev-view": [
      "8b58fb0e109c3f0e01a9/shared.js",
      "8b58fb0e109c3f0e01a9/dev-view.js"
    ],
    "global": [
      "8b58fb0e109c3f0e01a9/shared.js",
      "8b58fb0e109c3f0e01a9/global.js"
    ],

It would be useful if shared did appear in the chunk list as its own entry.

(First, my apologies, I don't want to derail the thread at #41.)

In this case, there are two projects dependent on each other, and compatibility with old versions can't break. This would take a lot of time for @owais to QA.

In addition, there are different versions of webpack and there could be variations in between those.

@owais Would it be helpful to have more contributors / maintainers? Any updates as to how busy you are / if you're using this in production and can support it?

In my personal case: I'm using Django 2.2 with Webpack v4 (with codesplitting), so this lead me to issues that haven't been merged yet here and https://github.com/owais/django-webpack-loader

Hello,

Now that we have tests. I want to rewrite plugin to es6 syntax and add following changes :

• Support only webpack >4
• Handle splitChunk option of Webpack to add files related of a chunk.
• Add integrity option to handle https://www.w3.org/TR/SRI/

What do you think ? I'll start a pull request to show you changes that i want to made

I am in process of upgrading the webpack to v5. I encountered an issue after upgrading webpack-bundle-tracker.
When I export multiple configurations from webpack config - it is a feature introduced in webpack 3 the new version of webpack-bundle-tracker does not work as expected. It randomly chooses only one configuration and creates stats for it.
I use webpack5 and the issue occurs only on webpack-bundle-tracker1.0.0. I checked on version v0.4.3 and it works as expected.

I created a small reproduction for you

But this requires a minor version release.