feat(intl-messageformat)!: convert to esm#5456
Closed
longlho wants to merge 1 commit into12-14-feat_formatjs_editor_convert_to_esmfrom
Closed
feat(intl-messageformat)!: convert to esm#5456longlho wants to merge 1 commit into12-14-feat_formatjs_editor_convert_to_esmfrom
longlho wants to merge 1 commit into12-14-feat_formatjs_editor_convert_to_esmfrom
Conversation
Member
Author
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has required the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
This was referenced Dec 14, 2025
Merge activity
|
graphite-app Bot
pushed a commit
that referenced
this pull request
Dec 14, 2025
### TL;DR Convert `intl-messageformat` package to ESM-only format with proper `.js` extensions. ### What changed? - Updated `package.json` to specify `"type": "module"` and added proper exports field - Added explicit `.js` extensions to all import/export statements - Removed CommonJS output by setting `skip_cjs = True` in Bazel build config - Removed `main` and `module` fields from package.json as they're no longer needed ### How to test? 1. Build the package with `yarn build` 2. Import the package in an ESM environment to verify it works correctly 3. Run tests to ensure functionality remains the same 4. Verify that the package can be properly imported in projects using ESM ### Why make this change? This change modernizes the package to use native ES modules, which provides better tree-shaking and aligns with the direction of the JavaScript ecosystem. Using explicit `.js` extensions in imports ensures compatibility with ESM's stricter module resolution rules, while removing CommonJS output simplifies the package structure and maintenance.
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.

TL;DR
Convert
intl-messageformatpackage to ESM-only format with proper.jsextensions.What changed?
package.jsonto specify"type": "module"and added proper exports field.jsextensions to all import/export statementsskip_cjs = Truein Bazel build configmainandmodulefields from package.json as they're no longer neededHow to test?
yarn buildWhy make this change?
This change modernizes the package to use native ES modules, which provides better tree-shaking and aligns with the direction of the JavaScript ecosystem. Using explicit
.jsextensions in imports ensures compatibility with ESM's stricter module resolution rules, while removing CommonJS output simplifies the package structure and maintenance.