Walkthrough

Two Pro packages received a main field in their package.json files to enable compatibility with ESLint resolvers that rely on the resolve npm package, which does not support Node.js conditional exports and only recognizes the main field.

Changes

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Possibly related PRs

• Fix broken file path links in documentation #2236 — Touches the same ReactOnRailsProNodeRenderer package with documentation updates to source path references

Suggested labels

bug, review-needed

Suggested reviewers

• AbanoubGhadban

Poem

🐰 A main field here, a main field there,
Now ESLint can find us everywhere!
Both Pro packages, shining bright,
Legacy tools see the light. ✨

Pre-merge checks and finishing touches

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Code Review - PR #2256

Summary

This PR adds the main field to both Pro packages for compatibility with legacy module resolvers. The change is well-justified, minimal, and low-risk.

✅ Strengths

1. Well-Documented Rationale

• Issue Add main field to react-on-rails-pro and react-on-rails-pro-node-renderer package.json #2255 provides excellent context explaining the ESLint resolver problem
• Root cause analysis clearly identifies the resolve npm package limitation
• Historical context explains why this was missing (new packages created without main field)

2. Consistency with Existing Patterns

• Matches the open-source react-on-rails package which already has both main and exports
• The main field values correctly point to the same default exports:
  • react-on-rails-pro: lib/ReactOnRails.full.js matches exports['.'].default
  • react-on-rails-pro-node-renderer: lib/ReactOnRailsProNodeRenderer.js matches exports['.'].default

3. Zero Breaking Changes

• Modern tools (Node.js 12.20+, webpack, Vite) will continue using exports
• Legacy tools get a fallback via main
• This is purely additive - no existing behavior changes

⚠️ Required Testing (Per CLAUDE.md)

According to the project's testing guidelines in CLAUDE.md, build script changes require manual verification:

Critical Tests to Run:

# 1. Test clean install (MOST CRITICAL - simulates CI)
rm -rf node_modules
pnpm install -r --frozen-lockfile

# 2. Test build artifacts are created correctly
pnpm run build

# 3. Verify the paths exist as specified in package.json
ls -la packages/react-on-rails-pro/lib/ReactOnRails.full.js
ls -la packages/react-on-rails-pro-node-renderer/lib/ReactOnRailsProNodeRenderer.js

# 4. Test yalc publish (critical for local development)
pnpm run yalc:publish

# 5. Test package scripts work
cd packages/react-on-rails-pro && pnpm run prepare
cd ../react-on-rails-pro-node-renderer && pnpm run prepare

Why this matters:

• The main field is used by package managers and resolvers
• If the path is wrong, installs will fail silently for some users
• CLAUDE.md warns: "Path reference issues can break yalc publish silently"

📋 Test Plan Checklist

The PR's test plan should be completed:

• Verify the main field paths match the default export in each package's exports field ✅ (verified by review)
• Confirm ESLint import resolver no longer produces false positives for pro package imports (needs manual testing)

Additional recommended tests:

• Run pnpm run build and verify artifacts exist at specified paths
• Test pnpm run yalc:publish succeeds
• Test installation in a project using eslint-import-resolver-node

🔍 Minor Observations

Path Verification

The paths look correct based on the source files:

• ✅ packages/react-on-rails-pro/src/ReactOnRails.full.ts → lib/ReactOnRails.full.js
• ✅ packages/react-on-rails-pro-node-renderer/src/ReactOnRailsProNodeRenderer.ts → lib/ReactOnRailsProNodeRenderer.js

Both packages have prepare scripts that build these files if missing.

Documentation Impact

Consider updating these if they mention module resolution:

• Package README files (if they exist)
• Main documentation about importing Pro packages

🎯 Verdict

LGTM with testing requirements

The code change is correct and follows best practices. Before merging:

1. ✅ Complete the test plan checklist above
2. ✅ Ensure CI passes (especially install and build steps)
3. ✅ Manually verify pnpm run yalc:publish works

This is exactly the right fix for the ESLint resolver compatibility issue.

References

• Node.js package.json documentation
• resolve package issue #222 (explains why legacy resolvers don't support exports)
• CLAUDE.md section on "Testing Build and Package Scripts"

size-limit report 📦