devops: externalize peer dependencies#18
Conversation
These should NOT be bundled.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 58571377f9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // Bundle, but keep un-bundled all public dependencies. | ||
| external: Object.keys({ | ||
| ...pkg.dependencies, | ||
| ...pkg.peerDependencies, |
There was a problem hiding this comment.
Don't make
flakiness-report a new runtime dependency
For consumers that currently install only @flakiness/sdk (or receive it transitively), this line turns @flakiness/flakiness-report into a new runtime requirement. src/reportUtils.ts:3-4 pulls normalizeReport and validateReport into the published entry bundles, and those modules use runtime symbols from the peer package (src/normalizeReport.ts:72, src/validateReport.ts:11), so lib/index.js/lib/browser.js will now ship bare @flakiness/flakiness-report imports instead of bundled code. Updating to this release would therefore start failing with module-resolution errors unless the host explicitly adds the peer, which is a breaking change rather than an internal build tweak.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Yes, this works as expected
These should NOT be bundled.