Repository navigation
Fix: make es-components lib/cjs output resolvable by strict ESM loaders - #922
Open
JavierHuanca wants to merge 7 commits into
Open
JavierHuanca wants to merge 7 commits into
JavierHuanca wants to merge 7 commits into
Conversation
Adds explicit module boundaries and fixes dependency externalization so
es-components can be consumed through native/strict ESM resolvers
(e.g. esm.sh), without changing behavior for existing CJS, bundler, or
UMD consumers.
- package.json: add an exports map for . and ./build-utils/jest,
pointing import at lib/index.js and require at cjs/index.js,
alongside the existing main/module/types fields.
- rollup.config.mjs: write a nested package.json into cjs/ and lib/
after build ({type:commonjs} / {type:module}) so resolvers
don't have to guess the module format from the ambiguous .js
extension. Also stop wildcard-externalizing text-mask-addons for the
cjs/lib build, since it's imported via extensionless subpaths that
only CJS/bundler resolution tolerates.
- getPackageExternals.mjs: always bundle get-root-node-polyfill,
react-transition-group, and text-mask-addons instead of leaving them
external. Each is imported via a bare specifier pattern (missing
extension or directory import) that Node's strict ESM resolver
rejects, even though CJS/bundler resolution silently accepts it.
Verified built cjs/ and lib/ output resolves cleanly under Node's
native ESM loader (import()) and CJS require(); UMD bundle output is
unchanged; full es-components Jest suite (44 suites / 221 tests)
still passes.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
…age publishes The theme packages (es-components-wtw-theme, es-components-via-theme, es-components-wtw-legacy-theme) do not have npm Trusted Publishing configured yet, so npm's automatic OIDC attempt fails with E404 when id-token: write is present. Removing that permission forces npm to fall back to the existing NPM_TOKEN secret for all packages in the canary workflow, unblocking canary publishes without requiring admin action on npm. The real ci.yml/preprod-ci.yml release pipelines are left untouched pending a team decision. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
The NPM_TOKEN secret used by this workflow does not have publish access to es-components-wtw-theme, es-components-via-theme, or es-components-wtw-legacy-theme (confirmed by identical E404s with and without OIDC). Mark them private in the ephemeral CI checkout only (never committed) so lerna skips them and es-components can still publish a canary build on its own. Revert once an admin widens the token's scope or configures npm Trusted Publishing for those packages. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
lerna refuses to publish with an EUNCOMMIT error if the working tree has uncommitted changes, so the private=true marker set on the theme packages in the previous commit needs to be committed locally in the ephemeral CI checkout (never pushed to origin) before lerna publish runs. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Removing id-token: write broke es-components' own publish, which turns out to rely on working OIDC Trusted Publishing (not the classic NPM_TOKEN as assumed). Only the theme packages lack Trusted Publishing setup; the private-package exclusion step added earlier already handles that correctly, so restoring this permission is all that's needed. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Reverting the temporary workaround now that the real root cause is identified as an expired NPM_TOKEN. Once Steve regenerates the token, all 4 packages should publish normally again, so this workaround is no longer needed. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Trusted Publishing is now enabled on npm, but only registered for one workflow file, so the theme packages get E403 when publishing from canary-publish.yml. Re-applying the private-flag workaround so es-components can publish a canary build on its own in the meantime. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Adds explicit module boundaries and fixes dependency externalization so es-components can be consumed through native/strict ESM resolvers (e.g. esm.sh), without changing behavior for existing CJS, bundler, or UMD consumers.
Verified built cjs/ and lib/ output resolves cleanly under Node's native ESM loader (import()) and CJS require(); UMD bundle output is unchanged; full es-components Jest suite (44 suites / 221 tests) still passes.