fix: import jsonc-parser's ESM entry to fix broken dist bundle

[prdai]

Summary

• v1.2.0 (current @v1) broke every consumer: dist/index.cjs throws Error: Cannot find module './impl/format' on load (see BitByBit-B3/neo-project-labor-tracker-poc#199, run 28885042388).
• Cause: jsonc-parser has no exports map, so Node resolution falls back to its main field — a UMD wrapper whose CJS branch does require("./impl/format") at runtime. bun build's bundler doesn't inline that relative require, so the shipped dist/index.cjs has a dangling require to a file that only exists inside node_modules, not in the published action.
• Fix: import jsonc-parser/lib/esm/main.js directly in src/config.ts — static ESM imports get inlined correctly by the bundler.

Test plan

• bun run typecheck
• bun test (9 pass)
• bun run build then node dist/index.cjs — no longer crashes on module resolution (fails only on missing action inputs, as expected outside actions/*)
• Tag a patch release (v1.2.1) and re-point v1 once merged, so downstream @v1 pins pick this up

Summary by CodeRabbit

• Chores
  • Updated an internal package reference used for configuration parsing. No user-facing behavior, features, or settings were changed.

[coderabbitai]

Walkthrough

The import path for the parse function used by parseJsonc in src/config.ts was changed from the jsonc-parser package root to its ESM entry point jsonc-parser/lib/esm/main.js. No other code was modified.

Changes

Import Path Update

Layer / File(s)	Summary
jsonc-parser import source src/config.ts	Import of parse switched from jsonc-parser to jsonc-parser/lib/esm/main.js.

Estimated code review effort: 1 (Trivial) | ~2 minutes

Poem

One little import, swapped with care,
ESM path now hopping in the air.
A single line, direct and true,
jsonc-parser gets a fresher view. 🐰

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly matches the change: switching jsonc-parser to its ESM entry to fix the broken dist bundle.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/jsonc-parser-cjs-bundle

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/config.ts`:
- Line 2: The import in config parsing is using a deep internal path from
jsonc-parser, which should be avoided. Update src/config.ts to use the package’s
public entrypoint via the parse symbol, and make dependency handling safer by
either pinning jsonc-parser to an exact version in package.json or adding a CI
smoke test that runs the build and launches the compiled entrypoint so future
updates can’t break this silently.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: f509dbfb-4c33-49b6-823f-97045b8064ce

📥 Commits

Reviewing files that changed from the base of the PR and between 6a8dbfd and 1c7fb3d.

⛔ Files ignored due to path filters (1)

• dist/index.cjs is excluded by !**/dist/**

📒 Files selected for processing (1)

• src/config.ts

[coderabbitai]

🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick win

🧩 Analysis chain

🌐 Web query:

Is jsonc-parser 3.x lib/esm/main.js path guaranteed stable, or could a future 3.x patch release change internal lib layout without an exports map?

💡 Result:

The path lib/esm/main.js in the jsonc-parser 3.x library is not guaranteed to be stable and should not be considered a stable public interface. While this path is currently used as an entry point in the 3.x release [1], the library lacks a formal package.json exports map [2], which is the standard mechanism in Node.js to explicitly define and guarantee public API surfaces. Reliance on direct internal file paths is fragile and subject to change without notice in patch releases, as the internal directory structure is an implementation detail rather than a committed public contract [3]. Historical context from the project indicates that the package has faced challenges with its module system and entry points [4]. Because the library's internal layout is governed by its build system configuration [1][2], any updates to that system or a move to modernize the module distribution (e.g., introducing an exports map) could result in the relocation or renaming of internal files like lib/esm/main.js. To ensure your application remains stable, you should rely only on the documented public exports of the package. If you must consume the library, reference it through its defined entry points in package.json (such as the main or module fields) rather than hardcoding paths to internal files [2].

Citations:

• 1: https://deepwiki.com/microsoft/node-jsonc-parser/7.1-project-structure
• 2: https://deepwiki.com/microsoft/node-jsonc-parser/7.2-build-system
• 3: https://deepwiki.com/microsoft/node-jsonc-parser/6-implementation-details
• 4: Fix ESM exports microsoft/node-jsonc-parser#78

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf 'package.json:\n'
cat -n package.json | sed -n '1,220p'

printf '\nRelevant jsonc-parser references:\n'
rg -n "jsonc-parser|lib/esm/main\.js|exports" -S . --glob '!node_modules' --glob '!dist' --glob '!build' || true

printf '\nsrc/config.ts:\n'
cat -n src/config.ts | sed -n '1,120p'

Repository: BitByBit-B3/cf-pr-preview-action

Length of output: 5786

---

Avoid the deep import from jsonc-parser.
src/config.ts:2 reaches into an internal file path, while package.json:46 still allows ^3.3.1. Either pin jsonc-parser exactly or add a CI smoke test that runs bun run build && node dist/index.cjs so a dependency update can’t break this silently.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/config.ts` at line 2, The import in config parsing is using a deep
internal path from jsonc-parser, which should be avoided. Update src/config.ts
to use the package’s public entrypoint via the parse symbol, and make dependency
handling safer by either pinning jsonc-parser to an exact version in
package.json or adding a CI smoke test that runs the build and launches the
compiled entrypoint so future updates can’t break this silently.