ref(build): Introduce central build directory to packages with bundles

[Lms24]

Background

This is the continuation of the build directory restructuring started in #4688. The goal is to put everything building related (i.e. compiled code and non-code assets for NPM tarballs) into one central directory.

Changes

This PR introduces the central build directory to all our packages producing CDN bundles in addition to NPM tarballs:

• Browser
• Integrations
• Tracing
• WASM

The new build directory for packages with CDN bundles will have the following structure:

<sdk>/
├─ build/
│  ├─ bundles/
│  │  ├─ CDN bundles (rollup) (es5, es6) (+min, maps)
│  ├─ npm/
│  │  ├─ build/ <-- this is just temporary and will be gone with v7
│  │  │  ├─ CDN bundles (rollup) (es5, es6) (+min, maps)
│  │  ├─ cjs/    // dist until v7
│  │  │  ├─ CJS modules (+maps)
│  │  ├─ esm/
│  │  │  ├─ ES6 modules (+maps)
│  │  ├─ types/
│  │  │  ├─ *.d.ts files (+maps)
│  │  ├─ package.json
│  │  ├─ LICENSE
│  |  ├─ README.md
│  ├─ npm-legacy/ <-- this is not included in this PR but will come once we introduce our ES5 legacy NPM tarballs
├─ ...

Inside the tarball, the directory structure is as follows*:

sentry-<sdk>-<version>.tgz/
├─ build/                        // bundles will be removed from the tarball in v7
│  ├─ CDN bundles
├─ dist/                        // will be changed to 'cjs' in v7
│  ├─ CJS modules (+maps)
├─ esm/
│  ├─ ES6 modules (+maps)
├─ types/
│  ├─ *.d.ts files (+maps)
├─ package.json
├─ LICENSE
├─ README.md

A small note here: CDN bundles will be removed from the tarball in v7. Until then, they remain in the build directory in the tarball, which should not be mistaken for the central build directory described above. I know, this is confusing but otherwise, this would be a breaking change for people unofficially using our CDN bundles e.g. via UNPKG.

*for WASM, CDN bundles are not added to the tarball as they were not previously included.

Procedure:

• running yarn build will start compilation (no changes on this end).
• running yarn build:npm starts the prepack script and subsequently creates the NPM tarball. The prepack.ts script:
  • copies all additional (non-code) files into build/npm
  • temporarily copies CDN bundles into the build/npm/build until v7
  • adjusts package.json entry points to align with the NPM tarball structure described above
  • deletes unnecessary properties from the copied package.json
• running yarn build:npm will pack the NPM tarball from inside build/npm and save it in the package root directory.

Additional Information

"But what about Vue and WASM bundles!?" you might ask. Well, it turns out, those are created but not published. So we actually do not need to create them either for every build. To not clutter this PR too much, I'll deactivate the bundle creation by default in a separate one coming soon (TM).

How to best review: Every commit represents the changes for one package. For reviewing, it might be helpful to go through the changes commit-by-commit, starting with fd0da2c. I double and triple checked the correct tarball creation but given that a bug in this PR could easily break users, a second pair of eyes can't hurt.

ref: https://getsentry.atlassian.net/browse/WEB-780

[lobsterkatie]

In addition, yarn build starts the postbuild script which:

• copies all additional (non-code) files into build/npm
• temporarily copies CDN bundles into the build/npm/build until v7
• adjusts package.json entry points to align with the NPM tarball structure described above

It's fine if you want to leave it like this for this PR (and the one making this same change to the non-bundle packages), and then make a wholesale change separately, but the more I think about it, the more I think this work shouldn't happen on every build, since it's really only relevant to publishing and only a tiny fraction of builds go on to be published.

[lobsterkatie]

How to best review: Every commit represents the changes for one package. For reviewing, it might be helpful to go through the changes commit-by-commit

Super tiny nit: Especially for a PR where the idea is to have each commit be one idea, and where you want to look at each commit as an entity in and of itself, it'd be great to have the first commit's message explain what that commit is (as all the others' respective messages do), rather than just be the PR title.

[lobsterkatie]

LGTM!

[Lms24]

the more I think about it, the more I think this work shouldn't happen on every build

Yes you're right. My initial idea was to make the postbuild->prepack change in a separate PR but tbh I think this can still fit in this one. Especially, when considering that I'm basing the rest of the build dir conversions on this work here so I'd essentially be adding things to that branch of which I know that I'd change them directly afterwards again.

it'd be great to have the first commit's message explain what that commit is

Good point, thanks for mentioning it. I'll do better with the next PR coming soon.

[github-actions]

size-limit report 📦

Path	Size
@sentry/browser - ES5 CDN Bundle (gzipped + minified)	20.21 KB (0%)
@sentry/browser - ES5 CDN Bundle (minified)	65.26 KB (0%)
@sentry/browser - ES6 CDN Bundle (gzipped + minified)	18.89 KB (-0.01% 🔽)
@sentry/browser - ES6 CDN Bundle (minified)	58.27 KB (0%)
@sentry/browser - Webpack (gzipped + minified)	23.23 KB (0%)
@sentry/browser - Webpack (minified)	82.17 KB (0%)
@sentry/react - Webpack (gzipped + minified)	23.27 KB (0%)
@sentry/nextjs Client - Webpack (gzipped + minified)	47.81 KB (-0.46% 🔽)
@sentry/browser + @sentry/tracing - ES5 CDN Bundle (gzipped + minified)	26.15 KB (-0.01% 🔽)
@sentry/browser + @sentry/tracing - ES6 CDN Bundle (gzipped + minified)	24.5 KB (-0.01% 🔽)