On the PR I opened few days ago, the GitHub Actions didn't run.
As I don't have permissions to the repo, as it was a PR from a fork, I could not see what the problem see.

Actions seem to have run just fine on the previous PR, done by @davidhouweling

Hello! Thanks for this great tool. I just got here by reading the excellent article on medium. I am considering setting up this project into our ci integration, but I could not figure out how to get a previous stats.json from a previous build to compare with the current stats.json? Do you have a real-world example with Github actions, for instance?

I can think of many possibilities, but I wonder if you already have a GitHub workflow ready to go?

Thank you.

At present we don't have an automated security audit which could fix issues automatically from dependencies which might have security vulnerabilities.

GitHub has a built in system using dependabot or alternatively we can use a different tool such as Snyk or renovate.

Need to discuss here and then implement what we think is most appropriate.

Reference: #7

Currently webpack-bundle-delta detects duplicate dependencies when they are in the same chunk which is awesome, however it would be good to push this one step further with duplicate dependency detection across all chunks. This should be an opt-in feature behind a flag as by default not all applications would need it.

The idea behind this is that some complex applications will have chunks brought in by other chunks (EG: dynamic imports) which could end up with duplicate dependencies. Take the following example:

Example

// bundle-a.js
require.ensure('bundle-c.js');
deps: [
  'cool-dependency': ^2.6.0,
]

// bundle-b.js
require.ensure('bundle-c.js');
deps: [
  'cool-dependency': ^3.0.2,
]

// bundle-c.js
deps: [
  'cool-dependency': ^3.1.0,
]

Any page that uses bundle-a will have have [email protected] and [email protected] which we would want to know be reported on the PR.

The following improvements should be made to provide a more robust and verified package:

• Move linting to its own workflow: at present it lints for every build, but really we only need it to lint once, so would be better to move it to its own build pipelines to make the other ones a little faster
• Create integration pipelines:
  • at present we have build and test pipelines for each version of node we are supporting, but this doesn't actually prove it would be fully functional across the different operating systems
  • Windows is the notable one which may work differently than Mac and Linux, so having integration pipelines which run a set of integration tests across the varying node versions on each platform ensures that we don't miss any users (3 x 3)
  • This should be doable by creating a really basic integration test using the existing fixtures and the local command

At present chores are not part of release notes (as we could see from https://github.com/trainline/webpack-bundle-delta/releases/tag/0.1.2) where @santino made the note about why the change occurred.

Adding "chores" would mean that the release process should be clearer for simple things like chores being merged and released.

At present webpack-bundle-delta only supports webpack v4. As webpack v5 has been our for a few months now we need to look at adding support for it.

Based on initial investigations the following likely cause of action needs to be taken:

• Use package alias remapping to rename the present webpack to webpack 4 as well as @types/webpack
• Webpack 5 does comes with types, however it doesn't have stats types, so we need to create a PR for webpack itself to output the stats defintions, making sure the stats are aligned
• Consumed the new version of webpack which would contain the stats
• Update WBD code to logically work out what to do given each version that is passed to it