fix(common): add resolveJsonModule to ts-node compilerOptions (fixes #816)

[just-jeb]

PR Checklist

• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

Importing .json files in TypeScript webpack configs (e.g. import * as pkg from './package.json') fails with TS2732 even when the user's tsconfig has resolveJsonModule: true, because ts-node's explicit compilerOptions override in load-module.ts does not include resolveJsonModule, which resets it to the default false.

Issue Number: #816

What is the new behavior?

resolveJsonModule: true is added to the explicit compilerOptions passed to ts-node.register(), so JSON imports work in TypeScript webpack config files.

New integration test: custom-webpack: TS config with JSON import.

Does this PR introduce a breaking change?

[ ] Yes
[x] No

resolveJsonModule is a permissive flag — it enables a behavior that was previously rejected. No existing valid config can be broken by this change.

Other information

Note: This PR modifies load-module.ts which is also rewritten by PR #1659. If #1659 merges first, this fix needs to be applied to register-ts-project.ts instead.

[just-jeb]

Thanks for the PR!

After discussion, we have decided not to add resolveJsonModule: true at the builder level for now. The reasoning:

• resolveJsonModule is a TypeScript compiler option that belongs in the user tsconfig.json. The builder already passes the user tsconfig to ts-node via the project option, so users can opt in by adding it there.
• Silently injecting it could surprise users who have explicitly set it to false, or cause subtle behavioral differences.
• If we decide to make it a default in the future, that would be a breaking change appropriate for a major version bump.

The workaround is straightforward: add resolveJsonModule: true to the tsconfig that your webpack config uses. We will update the docs to make this clearer.

Appreciate the contribution!

[just-jeb]

Correction to my previous comment: looking more carefully at the issue history, the reporter confirmed that adding resolveJsonModule to the user tsconfig does NOT fully solve it (it still fails for the karma builder). So the user-side workaround is incomplete.

The actual validated workarounds are:

• Use require() instead of import for JSON files in webpack configs
• Or fix it at the builder level by passing resolveJsonModule: true to ts-node

We are reconsidering the approach. Fixing it at the builder level is valid but would be a deliberate decision for a major version. Apologies for the premature close — we will reopen and track this properly.

[just-jeb]

Updated analysis after reading the code:

The root cause is that _tsNodeRegister passes an explicit compilerOptions object to ts-node, which replaces rather than merges with the user's tsconfig compilerOptions. This means a user cannot work around the issue by adding resolveJsonModule: true to their own tsconfig — the builder overrides it regardless. The only user-side workaround is require() instead of import.

There are two possible approaches to fix this properly:

1. Add resolveJsonModule: true to the explicit override — what this PR does. Simple, but opinionated.
2. Read the user's tsconfig compilerOptions and merge them into the override — more principled, respects any option the user has set.

Both approaches could be a breaking change for setups that rely on the current minimal override behavior. We are deferring this to the next major version. Keeping this PR open as a reference implementation for when that time comes.

[just-jeb]

Option 1 seems fine.