test(e2e): Add Node SDK re-exports consistency e2e test #10389
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As notified in #10384, we were missing quite a few exports in the Remix SDK. I fixed a couple of them in #10385 but wanted to do a proper audit of other SDKs where we have the same potential problem.
As a result, this PR introduces an e2e test that checks if all
@sentry/node
exports were re-exported in packages that depend on@sentry/node
. It's not a real e2e test, as there's no actual test application, but we only execute a script that imports various SDKs depending on@sentry/node
. However, IMO it makes a lot of sense to test the export of the final tarballs which we already have the infrastructure for in our e2e tests.Some remarks:
Example of failing CI job:
Background:
For reasons unknown to us, rollup seems to bundle
export * from "@sentry/node"
statements into thedefault
property of higher level SDKs. Therefore we have to individually re-export APIs from@sentry/node
in each SDK depending on the Node package. This has a lot of potential for unintended export inconsistencies.I'm still skipping some packages on purpose as these currently actually still have missing exports. Will fix them in follow-up PRs and opt them in to this test. Decided on this order because this makes my decisions clearer as to what we actually re-export in the packages.