Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for dynamicCompileOptions in VSCode #2436

Open
bfanger opened this issue Jul 7, 2024 · 5 comments
Open

Add support for dynamicCompileOptions in VSCode #2436

bfanger opened this issue Jul 7, 2024 · 5 comments
Labels
feature request New feature or request

Comments

@bfanger
Copy link
Contributor

bfanger commented Jul 7, 2024

Description

The vite plugin allows setting compileOptions based on filename which is useful for settings like runes.

At the moment the vitePlugin.dynamicCompileOptions is ignored by the language-server and warnings like:

`count` is updated, but is not declared with `$state(...)`.  Changing its value will not correctly trigger updates

are not visible in the editor when the { runes: true } is set by the dynamicCompileOptions function and no runes are used yet.

Proposed solution

Take the dynamicCompileOptions into account and use the same final compileOptions as is used for real.

Alternatives

Not using dynamicCompileOptions and relying on a preprocessor to enable runes mode.

Additional Information, eg. Screenshots

sveltejs/svelte#12327

@jasonlyu123
Copy link
Member

The option passed into vite plugin svelte is not visible from outside so it won't be possible to read that. It will need to be option in svelte.config.js. But l don't think adding an option solely for work around an issue make much sense.

Probably better you just add more precise check in dynamicCompileOptions to exclude rune mode packages. The language server also supports nested svelte.config.js so you can also add one in the nested directory only for the editor.

@bfanger
Copy link
Contributor Author

bfanger commented Jul 7, 2024

The dynamicCompileOptions are defined in svelte.config.js:

// svelte.config.js
export {
  compilerOptions: { runes: true },
  vitePlugin: {
    dynamicCompileOptions({ filename }) {
      if (filename.includes("node_modules")) {
        return { runes: undefined };
      }
    },
  },

And the dynamicCompileOptions wants:

dynamicCompileOptions?: (data: {
  filename: string;
  code: string;
  compileOptions: Partial<CompileOptions>;
}) => Promise<Partial<CompileOptions> | void> | Partial<CompileOptions> | void;

which are all available in the language server.

Nested svelte.config.js may work in de language server, but they are ignored in SvelteKit (it was one of my suggestions in 12327 which was quickly marked as non-planned but the related sveltejs/svelte#11523 is still open)

@jasonlyu123
Copy link
Member

We also don't support the vitePlugin option in the svelte.config.js. So it'll be the same as adding an dedicated option. It might even be slightly worse than a new top-level option since there might be people adding option there expecting it will only be read by vite plugin svelte.

About nested svelte.config.js. I know it's ignoed in sveltekit so it can be used as temporary workaround since only the editor will read it. But a more precise check in dynamicCompileOptions to only enable rune:true for rune mode libary will make more sense and give you more control.

@dominikg
Copy link
Member

dominikg commented Jul 7, 2024

I added dynamicCompileOptions to vite-plugin-svelte a while ago as an experimental option and it was promoted to a stable option since. Because it only works with vite-plugin-svelte it's not on the top-level of svelte.config.js

IF we add it to the top, then it would have to be supported by svelte-loader, rollup-plugin-svelte etc. too.

@dummdidumm
Copy link
Member

We'll likely build this into Svelte itself in the sense of having a svelte/config or @sveltejs/config and enhancing svelte.config.js so that compilerOptions can also take a function similar to dynamicCompileOptions. Once these steps are implemented we should be able to support it in here aswell.

@dummdidumm dummdidumm added the feature request New feature or request label Jul 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants