Adds the ability to specify a custom build output directory.

Notes:

• Thanks for your great work on this! Looking to make this change to make it usuable in a Nx monorepo I work with, where the app is built to a path that looks like dist/apps/... (per Nx recommendations)
• Tests are passing, but didn't add any new tests — I think this would require creating a completely new fixture with a different package.json. If you'd like, I can add a new test suite
• Could probably pull BUILD_OUTPUT_DIRECTORY into a file named utils.js or something 🤷

Thanks to create great nextjs analizer. My project introduced this github action.

Run npx -p nextjs-bundle-analysis generate to generate the file, but the eof was missing. eof was missing in the original template file, so added it.

I think this should fix https://github.com/hashicorp/nextjs-bundle-analysis/issues/7 👀

The difference is part of the budget column, but not all of it, so we want to render this column even if we aren't rendering the diff.

Thanks @jescalan for this fantastic project!

Trying to get up and running here, and hitting this error:

> npx nextjs-bundle-analysis generate

Cannot find module '~/my-project/.next/analyze/__bundle_analysis.json'
Require stack:
- ~/.npm/_npx/38403/lib/node_modules/nextjs-bundle-analysis/compare.js

I think we'll need to conditionally require here. Thoughts?

Inspired by preactjs/compressed-size-action, this PR adds a new configuration option minimumChangeThreshold to hide pages that have changes below the configured threshold.

By default, the threshold is 0, meaning any changes to the global bundle size or the size of a page will cause them to be included in the report.

Im using a working directory, which is used for every run. During "Upload bundle" i had to add it there too:

path: ./apps/FOO/.next/analyze/__bundle_analysis.json

But now it fails in the comparison step and i have no clue why...

Download base branch bundle stats:

==> Conclusion: success
==> Branch: main
==> RunID: 1290529608
==> Artifact: 97934011
==> Downloading: bundle.zip (288 B)
  inflating: .next/analyze/base/bundle/__bundle_analysis.json

So it seems to inflate something. No clue where, also used our working directory there, no success.

Error in next step

Run ls -laR .next/analyze/base && npx -p nextjs-bundle-analysis compare
ls: cannot access '.next/analyze/base': No such file or directory

Hi,

Thank you for the amazing library! I was going through the code and I was wondering that where in the code, bundle for base branch is saved to the path analyze/base/?

Thanks in advance!

Hello,

I am trying to use this GHA for our project that is using a custom build directory. However, whenever the action step reaches Analyze bundle it fails, because the command npx -p nextjs-bundle-analysis report seems to still want to check the default .next build directory.

No build output found at "myproject/.next" - you may not have your working directory set correctly, or not have run "next build"

Yet in package.json:

"buildOutputDirectory ": "build",

This GitHub Action depends on having @next/bundle-analyzer correctly configured in one's Next.js project right? If so, it may be useful to put that in the docs somewhere (happy to put up a PR). Although a very "duh" moment in retrospect, I only figured that out by reading the Action's steps and seeing it's looking for /next/analyze/__bundle_analysis.json

Hi there 👋

This PR was auto-generated as part of an internal review of public repositories that are not in compliance with HashiCorp's licensing standards.

Frequently Asked Questions

Please approve and merge this PR in a timely manner to keep this source code compliant with our OSS license agreement. If you have any questions or feedback, reach out to #proj-software-copyright.

Thank you!

Made with :heart: @HashiCorp

This PR addresses #4 and adds a workflow step to cache next's build cache & restore on subsequent workflow runs

Consumers may customize the cache key to be more strict

Hi! Our team recently moved to using a monorepo so our Next.js app was no longer in the root directory of the repo.

According to the comment for defaults.run.working-directory I updated that to point to the subdir our app lives in, but this didn't work - on main no artifacts were found to be uploaded, and then branch builds would fail because they had nothing to compare against.

It turns out defaults.run.working-directory only affects run steps, but uses steps will still run from the root! This means the paths given to uses: actions/cache@v2, uses: actions/upload-artifact@v2 and uses: dawidd6/action-download-artifact@v2 also need to be prefixed with the app subdirectory.

This PR adds comments to make this more obvious. Cheers!

Setting action output using ::set-output was deprecated on 11th Oct 2022. See https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/ I've tried several approaches to switch to the new variant, but all of them have some kind of issues with multiline strings. So I tried something completely different and implemented it using actions/github-script.

By default generate a job configuration that executes the up-to-date version of the code.

Or alternatively just release a new version. The current release is from February and predates the minimumChangeThreshold setting documented in the README, so the current situation wastes people's time troubleshooting why that setting doesn't work. :-)

The existing template sets up a comparison against the latest bundle analysis on the target branch. But that misrepresents the effect of the current PR. The current PR might have no effect on bundle sizes but they have changed in the meantime on the target branch for some unrelated reason, and then the comparison will incorrectly imply that the current PR is having the inverse effect.

So instead, default to running the comparison against the bundle analysis on github.event.pull_request.base.sha, which is the latest commit on the target branch that is also an ancestor of the tip of the PR branch (either by being the original commit from which the PR branch was forked, or the latest commit on the target branch that has been merged into the PR branch).

Hi! Awesome library. One thing that would help us - while we have a budget set, seeing the raw size of the gzip diff is almost always wanted, whereas the current setup hides it if the budget is set.

I just added an option for allowing this.

Implement a custom wrapper around next build which exits after the webpack build completes. This should make the analysis run much faster, and will generally simplify setups because the data fetching that happens during static generation can often require additional environment variables and/or secrets.

See: https://github.com/hashicorp/web-platform-packages/tree/main/packages/tools#next-build-webpack-only