Runes mode enforcement is currently too hamfisted

[GrygrFlzr]

Followup to #944 #952 and #984
Currently, the default config generated by sv cli uses this function:

dynamicCompileOptions: ({ filename }) =>
			filename.includes('node_modules') ? undefined : { runes: true }

This currently just checks for the existence of node_modules in the filename path for determining if the compiler should use runes mode.
As a result:

1. It does not respect any existing <svelte:options runes={false}> in .svelte files
   • edit: corrected, see comments
2. It unintentionally forces runes mode for generated files in the .svelte-kit folder
   • edit: partially incorrect due to (1) being incorrect
3. It unintentionally skips a path like src/lib/leafnode_modules, or all paths if the username happens to be node_modules

A more complete solution could be instead to scope the changes to the src folder, and also skip .svelte files that contain <svelte:options as a "I know what I'm doing" hint.
Example function:

import { extname, join, relative } from 'node:path';
const srcDir = join(import.meta.dirname, 'src');
/** @type {import('@sveltejs/vite-plugin-svelte').PluginOptions['dynamicCompileOptions']} */
const dynamicCompileOptions = ({ filename, code }) => {
	const isOutOfSrc = relative(srcDir, filename).startsWith('..');
	// .svelte.ts and .svelte.js definitely require runes mode
	const isSFCWithOptionDeclared =
		extname(filename) === 'svelte' && code.includes('<svelte:options');

	return isOutOfSrc || isSFCWithOptionDeclared ? undefined : { runes: true };
};

However, I think sv cli is not the right place to apply this anyway, because if e.g. we want to update the function, that requires all users with generated configs to manually change their config; it is an inherently fragile execution of the concept.

Even the function I provided would be fragile against the user configuring a custom kit.files.src path.

[jycouet]

Thx for looking into this @GrygrFlzr

On your points

1. I was thinking that <svelte:options in .svelte files is taking precedence to dynamicCompileOptions. It's not the case? I'll check that.
2. In .svelte-kit, we have generated/root.svelte with <svelte:options runes={true} />, can we have other files? I'll investagate
3. You are right, your isOutOfSrc look more robust.

Yes, if it start to be a complexe thing, I fully agree, it should not be in sv.
Here originally, the intent was: "Hey, in new projects, default to rune". It seems to not be that straight forward to do that, and we should fix it somewhere.

I'll report back later today ✌️

[GrygrFlzr]

For (1), you are correct, it looks like <svelte:options> does take precedence already:

// config
dynamicCompileOptions: () => ({ runes: true })

<svelte:options runes={false} />
<script>
    let counter = 2;
    $: doubled = counter * 2;
</script>

<p>{counter} &times; 2 = {doubled}</p>
<button on:click={() => {
    counter++
}}>add</button>

Properly uses legacy mode.

---

A separate issue is entirely visual with the VS Code extension not resolving the dynamicCompileOptions, e.g. if I remove the svelte:options directive, it compiles as runes mode, but vs code extension thinks it's legacy mode:

I'll raise a separate issue for that in the right repo.

---

For (2), I think it should be just root.svelte, which always begins with <svelte:options runes={true} />, so given (1) appears to be a non-issue, it should be fine?

---

My suggestion in (3) actually looks more fragile with the fact that (1) is already properly respecting the svelte:options directive:

• kit.files.src is still a valid option to change
• hardcoding src would not respect kit.files.src
• it is difficult to dynamically resolve kit.files.src while we are in the middle of declaring the very same config file which is used to resolve it

I think it may make more sense instead to:

• retain the project root relative check (so that user named node_modules does not impact our resolution)
• check it is the entire folder name and not just a substring (so leafnode_modules does not get impacted, as strange of a naming scheme that may be)

e.g.

import { relative } from "node:path";
const nodeModulesPattern = /\bnode_modules\b/i;
/** @type {import('@sveltejs/kit').Config} */
const config = {
  // ...
  vitePlugin: {
    dynamicCompileOptions: ({ filename }) => {
      const relativePath = relative(import.meta.dirname, filename);
      return nodeModulesPattern.test(relativePath)
        ? undefined
        : { runes: true };
    },
  },
};

Or the non-regex version:

import { relative, sep } from "node:path";

/** @type {import('@sveltejs/kit').Config} */
const config = {
  // ...
  vitePlugin: {
    dynamicCompileOptions: ({ filename }) =>
      relative(import.meta.dirname, filename)
        .toLowerCase()
        .split(sep)
        .includes("node_modules")
        ? undefined
        : { runes: true },
  },
};

import.meta.dirname was experimentally added in node v21.2.0, v20.11.0, but was only marked stable in v24.0.0, v22.16.0 - do we need to use something else to resolve the dirname?

If we still wanted to exclude .svelte-kit specifically, we run into the issue that kit.outDir is both supported and configurable, so I think it's more pragmatic to ensure any files in there do have the svelte:option runes={true|false} declared (which we already do with root.svelte)

[sacrosanctic]

do we need to use something else to resolve the dirname?

no, we're already using this in eslint.config.js