Skip to content

feat(wasm): Add test against minified browser bundle #4526

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Feb 9, 2022

Conversation

lobsterkatie
Copy link
Member

@lobsterkatie lobsterkatie commented Feb 9, 2022

The current wasm integration test uses the browser bundle, and is therefore a quick smoke test of whether the bundle is legit. At least temporarily, this PR makes it test against the minified bundle, too, so it can act as a similar smoke test there. This is helpful as we're changing the bundling process, as it's an extra check to make sure we haven't broken the world.

Because this is a likely-temporary (ab)use of this integration test, it's done in the quickest and dirtiest way possible: the page which gets loaded is replicated, with the SDK bundle pointing to the minified version rather than the regular version. If we decide to keep testing against both bundles, we should do it in a more elegant way.

@github-actions
Copy link
Contributor

github-actions bot commented Feb 9, 2022

size-limit report

Path Base Size (c8b3691) Current Size Change
@sentry/browser - ES5 CDN Bundle (gzipped + minified) 19.69 KB 19.69 KB +0.01% 🔺
@sentry/browser - ES5 CDN Bundle (minified) 62.91 KB 62.91 KB +0.01% 🔺
@sentry/browser - ES6 CDN Bundle (gzipped + minified) 18.51 KB 18.51 KB +0.02% 🔺
@sentry/browser - ES6 CDN Bundle (minified) 56.8 KB 56.8 KB +0.01% 🔺
@sentry/browser - Webpack (gzipped + minified) 22.21 KB 22.21 KB 0%
@sentry/browser - Webpack (minified) 76.02 KB 76.02 KB 0%
@sentry/react - Webpack (gzipped + minified) 22.24 KB 22.24 KB 0%
@sentry/nextjs Client - Webpack (gzipped + minified) 46.31 KB 46.31 KB 0%
@sentry/browser + @sentry/tracing - ES5 CDN Bundle (gzipped + minified) 28.22 KB 28.23 KB +0.02% 🔺

// `index.html` save the browser bundle `src` value. In the long run, we should rig it so just the bundle can be
// passed in. (Or, once the new bundling process is nailed down, stop testing against the minified bundle, since
// that's not really what this test is for.)
['index.html', 'min-bundle.html'].forEach(pagePath =>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was going to suggest dynamically generating these using a template, but we should wait till the new bundling process is nailed down.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, that's exactly what I meant by passing the bundle in. If we decide to keep testing against both, a template is indeed probably the easiest way to do that. I'm not 100% convinced we'll even need to/want to separately test against the minified bundle once we've solved bundling, but that's a bridge we can cross when we get there.

@lobsterkatie lobsterkatie merged commit 156a289 into master Feb 9, 2022
@lobsterkatie lobsterkatie deleted the kmclb-wasm-test-against-minified-bundle branch February 9, 2022 16:20
lobsterkatie added a commit that referenced this pull request Feb 10, 2022
The current wasm integration test uses the browser bundle, and is therefore a quick smoke test of whether the bundle is legit. At least temporarily, this makes it test against the minified bundle, too, so it can act as a similar smoke test there. This is helpful as we're changing the bundling process, as it's an extra check to make sure we haven't broken the world.

Because this is a likely-temporary (ab)use of this integration test, it's done in the quickest and dirtiest way possible: the page which gets loaded is replicated, with the SDK bundle pointing to the minified version rather than the regular version. If we decide to keep testing against both bundles, we should do it in a more elegant way.
@AbhiPrasad AbhiPrasad added this to the Pre 7.0.0 Work milestone Feb 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants