Next-plugins: Publish stable version of @zeit/next-source-maps

[danilofuchs]

Many examples require users to use @zeit/next-source-maps pinned version 0.0.4-canary.1. This version was released 2 years (!) ago, and by now it should not be considered canary, and should be just bumped to 0.0.4.

[fabb]

I just wanted to create the same issue.

Commits on 0.0.4-canary.1: https://github.com/zeit/next-plugins/commits/%40zeit/next-source-maps%400.0.4-canary.1/packages/next-source-maps

Commits on 0.0.3: https://github.com/zeit/next-plugins/commits/%40zeit/next-source-maps%400.0.3/packages/next-source-maps

These two commits are missing from 0.0.3:

• https://github.com/zeit/next-plugins/commit/5ec7d7e6caea7d80e7866cf20668b480035424bd#diff-c19842d128230688815dc57a3a96df6a
• https://github.com/zeit/next-plugins/commit/6786c6c431d896757b870f112f89e1fcf7ac7ae6#diff-c19842d128230688815dc57a3a96df6a

[fabb]

@timneutkens?

[danilofuchs]

Considering their recent work on enabling source maps into the framework itself, this plugin might become obsolete (I might be wrong in that assumption)

https://github.com/vercel/next.js/pull/13018 implements source maps into production browser bundles.
https://github.com/vercel/next.js/pull/13049 seems to do something similar to server bundles

[fabb]

That would be nice!

[paambaati]

@timneutkens Once that lands, how does one hook into the sourcemap generation lifecycle in Webpack?

For example, https://github.com/honeybadger-io/nextjs-with-honeybadger/blob/master/next.config.js uses this plugin to upload the built sourcemaps to the Honeybadger service — Honeybadger is an error analytics service like Sentry.

I also use the same plugin to run custom scripts to upload the sourcemaps to LogRocket.

[kachkaev]

@paambaati we’ve been using a similar Sentry Webpack Plugin as a part of yarn build, but then switched to Sentry CLI. Now that the build is separated from source map upload, there is much more flexibility.

For example, you can upload source maps in a downstream pipeline, which does not share auth tokens with the build job (safer). You can retry the upload if it fails or you can skip it for certain environments.

Honeybadger seems to support this CLI approach too: https://docs.honeybadger.io/lib/javascript/guides/using-source-maps.html#uploading-your-source-map

curl https://api.honeybadger.io/v1/source_maps \
  -F api_key=PROJECT_API_KEY \
  -F revision=dcc69529edf375c72df39b0e9195d60d59db18ff \
  -F minified_url=https://example.com/assets/application.min.js \
  -F source_map=@path/to/application.js.map \
  -F minified_file=@path/to/application.min.js

Separating artifact creation and artifact distribution is probably the right way forward. Hope this helps your team too!

[paambaati]

@kachkaev Thanks for the insight. In your case, how are the sourcemaps generated in the first place? Are you using the experimental flag?

[kachkaev]

It’s experimental flag in my side projects, but what’s at work – I cannot currently recall. IMHO that does not matter much, as long as the source map files are valid.

Also, in one side project (deployed as a Node.js container) I'm using this funny trick: https://github.com/vercel/next.js/blob/989b6ad145b7539e09522766d3818126bb2c17fd/examples/with-sentry/server.js#L49

It removes any need to upload source maps to Sentry, because Sentry can fetch *.map files from a prod server as long as it provides a header matching process.env.SENTRY_TOKEN. Thus, you don’t bloat your Sentry storage space on each build and can deploy more often.

Not sure if Honeybadger allows for some similar trick, but it still looks worth mentioning here.

[georgiosd]

@kachkaev that's a cool approach - any idea why Vercel went the uploading sourcemaps way in canary?
https://github.com/vercel/next.js/tree/canary/examples/with-sentry

[kachkaev]

any idea why Vercel went the uploading sourcemaps way in canary?

with-sentry was relying on a custom server.js entry point, which made it incompatible with vercel as the deploy environment. That’s purely my speculation – the PR that replaces with-sentry with with-sentry-simple does not say anything.

[jaydenseric]

by now it should not be considered canary, and should be just bumped to 0.0.4.

It should be bumped to 1.0.0; 0.x releases are _really_ annoying as semver allows breaking changes in them so package managers treat them the same way as major releases and you have to manually dig into changelog entries to see if there is a breaking change or not to tell if the update is safe.

[timneutkens]

Closing in favor of https://github.com/vercel/next.js/pull/20267