fix: overwrite nodenext option when transpiling

[dummdidumm]

transpileModule treats NodeNext as CommonJS because it doesn't read the package.json. Therefore we need to override it. Also see microsoft/TypeScript#53022 (the filename workaround doesn't work). Fixes #11086

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

[changeset-bot]

🦋 Changeset detected

Latest commit: 9162fdd

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/package	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[benmccann]

thank you! I was just coming to a similar conclusion, but you beat me to it 😄

the other thing I've been wondering is if we should switch nodenext for node16. it seems a bit brittle to use nodenext as its meaning could change at any time and so i'm not sure if it's what we should encourage

[dummdidumm]

I think it's better to use nodenext because it means we're always up to date with regards to how module resolution is done.

[benmccann]

Actually, on giving this more thought, I think there's another issue with the way we're testing this. We seem not to be using the tsconfig.json created by create-svelte for testing and instead providing our own. If we used the created one then we would have caught the issue.

It feels to me like we should delete the typescript-esnext test. It's a pretty weird one. It doesn't test create-svelte at all. It tests creating a project with create-svelte and then that the user changed settings in a way that didn't break things. But why are we testing what the user is doing? They could make any set of changes.

And then we should update the typescript-nodenext test to not provide a tsconfig.json but use the one created by create-svelte. Because what happens if we later change the value to something other than esnext or nodenext?

[dummdidumm]

We should keep the tests, because it ensures that tsconfig settings we had a various points in time all work properly. The idea of having a "use create-svelte's current tsconfig" test is good.

[benmccann]

Oh, yeah, that makes sense. I didn't realize this was a package test and was thinking it was a create-svelte test 😆