-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
[V3 Runtime] Ensure JS package has parity with various node versions #3821
Conversation
|
WalkthroughThe changes involve updates to the Changes
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
v3/internal/runtime/desktop/@wailsio/runtime/package.json (1)
6-12
: Great implementation of the "exports" fieldThe addition of the "exports" field is an excellent improvement. It provides clear and precise control over how the package can be imported, which is crucial for maintaining compatibility across different environments. The structure looks correct, specifying separate paths for types and the main module.
One minor suggestion:
Consider adding a "default" export to handle cases where the importing environment doesn't support the conditional exports:
"exports": { ".": { "types": "./types/index.d.ts", "require": "./src/index.js", - "import": "./src/index.js" + "import": "./src/index.js", + "default": "./src/index.js" } },This ensures maximum compatibility while still taking advantage of the more specific import conditions when available.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
- v3/internal/runtime/desktop/@wailsio/runtime/package.json (1 hunks)
🧰 Additional context used
🔇 Additional comments (5)
v3/internal/runtime/desktop/@wailsio/runtime/package.json (5)
3-3
: Excellent addition of the "type" fieldAdding
"type": "module"
is a great improvement. It explicitly declares that this package uses ECMAScript modules, which is crucial for modern JavaScript development and ensures better compatibility across different Node.js versions.
4-4
: Version bump is appropriateIncrementing the version to "3.0.0-alpha.28" is correct. It reflects the changes made to the package structure and follows semantic versioning principles for pre-release versions.
15-15
: Repository URL format change is fine but optionalChanging the repository URL to use the
git+
prefix ("git+https://github.com/wailsapp/wails.git"
) is acceptable. This format can provide better integration with git-based workflows and is recognized by npm and other tools.However, it's worth noting that this change is optional, and the previous format was also valid and widely used. Both formats are supported by npm and other package managers.
Line range hint
1-41
: Appropriate removal of "main" and "types" fieldsThe removal of the "main" and "types" fields is correct and aligns with best practices when using the "exports" field. These fields are now effectively replaced by the more precise declarations in the "exports" field. This change helps prevent potential conflicts or confusion that could arise from having both the old fields and the new exports field.
Line range hint
1-41
: Overall, excellent improvements to package structure and compatibilityThe changes made to this
package.json
file are well-thought-out and address the PR objectives effectively. By implementing modern package.json features like the "exports" field and explicitly declaring the module type, you've significantly improved the package's compatibility with various Node.js versions.These modifications align well with current best practices and should resolve the issues identified by publint. The new structure provides clearer guidelines for how the package should be imported and used, which will benefit developers working with this package across different environments.
Great job on enhancing the robustness and usability of the @wailsio/runtime package!
In react native web |
Community member brought up our v3 runtime package not being compatable with various node runtime versions and checking via publint
Current issues can be seen: @wailsio publint
PR Resolves notes given by publint to ensure parity with various node versions.
Summary by CodeRabbit
These changes aim to streamline the development experience and improve compatibility with modern JavaScript module standards.