Repository: sveltejs/svelte-preprocess (ts)

Issue:
`svelte-check` fails when using TypeScript `customConditions` for subpath imports
### Describe the bug

In the project, we use [import subpaths in `package.json`](https://github.com/storybookjs/addon-svelte-csf/blob/17d18078bf20ae36e526ddf73a19e4fc4ef58aca/package.json#L17-L21).

In order for TypeScript to work _(for tests)_, we added import condition `"development"`.

Using the following [TypeScript config](https://github.com/storybookjs/addon-svelte-csf/blob/17d18078bf20ae36e526ddf73a19e4fc4ef58aca/tsconfig.json#L19) with `"customConditions"` breaks our [CI with `svelte-check`](https://github.com/storybookjs/addon-svelte-csf/actions/runs/9752315565/job/26915584737).

By first glance, I'm not sure if the first errors are misleading. I can't find where our TypeScript config gets overiden:

> [!CAUTION]
> Getting Svelte diagnostics...
>
> error TS5098: Option 'customConditions' can only be used when 'moduleResolution' is set to 'node16', 'nodenext', or 'bundler'.

I am not sure if the issue is related to `svelte-preprocess`, given the error trace paths. I've noticed there's a new version of this one `v6`. I can't see any connection in [CHANGELOG](https://github.com/sveltejs/svelte-preprocess/blob/main/CHANGELOG.md), which would be a possible reference to this issue.

Is there anything that can be done, without necessity to revert usage of subpath imports?

### Reproduction

https://github.com/storybookjs/addon-svelte-csf/tree/experimental-support-svelte-v5

### Expected behaviour

I expect it to not fail

### System Info

macOS 14
Terminal, used CLI `svelte-check`



### Which package is the issue about?

svelte-check

### Additional Information, eg. Screenshots

_No response_

Pull request:
fix: remove customConditions tsconfig option
...in order to prevent invalid config errors which could arise from us forcing a module resolution. fixes #646

### Before submitting the PR, please make sure you do the following

- [x] It's really useful if your PR relates to an outstanding issue, so please reference it in your PR, or create an explanatory one for discussion. In many cases features are absent for a reason.
- [x] This message body should clearly illustrate what problems it solves. If there are related issues, remember to reference them.
- [x] Ideally, include a test that fails without this PR but passes with it. PRs will only be merged once they pass CI. (Remember to run `pnpm lint`!)

### Tests

- [x] Run the tests with `npm test` or `pnpm test`


Patch:
diff --git a/docs/migration-guide.md b/docs/migration-guide.md
index e4b83bc..c753672 100644
--- a/docs/migration-guide.md
+++ b/docs/migration-guide.md
@@ -9,6 +9,7 @@
   - [Executing some function before preprocessing](#executing-some-function-before-preprocessing)
   - [Defining preprocessor properties](#defining-preprocessor-properties)
   - [Type-checking components](#type-checking-components)
+- [From `v5` to `v6`](#from-v5-to-v6)
 
 <!-- /code_chunk_output -->
 
diff --git a/src/transformers/typescript.ts b/src/transformers/typescript.ts
index d652a56..a04efbc 100644
--- a/src/transformers/typescript.ts
+++ b/src/transformers/typescript.ts
@@ -60,12 +60,17 @@ function getCompilerOptions({
 
   const compilerOptions: CompilerOptions = {
     target: ts.ScriptTarget.ES2015,
-    ...(convertedCompilerOptions as CompilerOptions),
+    ...convertedCompilerOptions,
     // force module(resolution) to esnext and a compatible moduleResolution. Reason:
     // transpileModule treats NodeNext as CommonJS because it doesn't read the package.json.
     // Also see https://github.com/microsoft/TypeScript/issues/53022 (the filename workaround doesn't work).
     module: ts.ModuleKind.ESNext,
-    moduleResolution: ts.ModuleResolutionKind.Node10,
+    moduleResolution:
+      convertedCompilerOptions.moduleResolution ===
+      ts.ModuleResolutionKind.Bundler
+        ? ts.ModuleResolutionKind.Bundler
+        : ts.ModuleResolutionKind.Node10,
+    customConditions: undefined, // fails when using an invalid moduleResolution combination which could happen when we force moduleResolution to Node10
     allowNonTsExtensions: true,
     // Clear outDir since it causes source map issues when the files aren't actually written to disk.
     outDir: undefined,
@@ -141,7 +146,10 @@ export function loadTsconfig(
   compilerOptionsJSON: any,
   filename: string,
   tsOptions: Options.Typescript,
-) {
+): {
+  options: ts.CompilerOptions;
+  errors: ts.Diagnostic[];
+} {
   if (typeof tsOptions.tsconfigFile === 'boolean') {
     return { errors: [], options: compilerOptionsJSON };
   }


Test patch:
diff --git a/test/transformers/typescript.test.ts b/test/transformers/typescript.test.ts
index 53c67e9..756affc 100644
--- a/test/transformers/typescript.test.ts
+++ b/test/transformers/typescript.test.ts
@@ -12,7 +12,7 @@ import {
 import type { Processed } from '../../src/types';
 import type { Diagnostic } from 'typescript';
 
-spyConsole({ silent: true });
+spyConsole({ silent: false });
 
 const EXPECTED_SCRIPT = getFixtureContent('script.js');
 
@@ -203,5 +203,22 @@ describe('transformer - typescript', () => {
       expect(code).not.toContain('&&=');
       expect(code).not.toContain('||=');
     });
+
+    it('should remove customConditions option if necessary to prevent config error', async () => {
+      const opts = sveltePreprocess({
+        typescript: {
+          tsconfigFile: false,
+          compilerOptions: {
+            // we force a different module resolution in our transformer which
+            // would fail if we wouldn't also remove the customConditions
+            moduleResolution: 'NodeNext',
+            customConditions: ['development'],
+          },
+        },
+      });
+      const preprocessed = await preprocess(template, opts);
+
+      expect(preprocessed.toString?.()).toContain('export var hello');
+    });
   });
 });