Support for ESM configs

[dummdidumm]

Describe the feature
Support loading ESM config files. Currently only CommonJS svelte.config files are supported because the code uses require to load it.

I think that this line needs to change to use import(..) . Note though that TS will transpile this to a require anyway, that's why you need to create a const dynamicImport = new Function('path', 'return import(path)'); function and use that one as a workaround (see microsoft/TypeScript#43329 for more info).

A Usecase
Support ESM svelte.config.js in SvelteKit

Alternatives
none

Additional context
Blocker for sveltejs/kit#936

[dominikg]

Needs support for async config from vite, this has been merged but not released vitejs/vite#2758

Also does this mean that going forward there will be no svelte.config.cjs and we should discourage its use or are both allowed?

And while we're at it, whats the list of locations vite-plugin-svelte should look for svelte.config.c?js ? (see #23 for context)

[dominikg]

Update, async config hook might be a better place: vitejs/vite#2800

[dummdidumm]

Both cjs and js should be supported. It should check .js first, then .cjs to be in line with the order how language-tools and SvelteKit (will) resolve it.

Regarding "where to look": I think this was never specified. But we should, at some point, to save us some maintenance 😄

[dominikg]

Initial code here https://github.com/sveltejs/vite-plugin-svelte/compare/feat/async-load-config-esm needs to wait until vite 2.16 is released and peer dependency updated.

should we try to get rid of everything non-esm and make vite-plugin-svelte itself a type: module too?

Here's another require call:

vite-plugin-svelte/packages/vite-plugin-svelte/src/index.ts

Line 161 in a2acab9

pkg = require(resolved);

, anything else?

[dummdidumm]

You also need to replace the require-relative dependency I think.

Making it a type: module may be a little much though, I don't know who else uses this plugin in which configs. If those are commonjs-configs they can no longer use your package. If you are certain that's not the case then go for it I'd say. If not, you could also make it dual both supporting ESM and commonjs through separate entry points if you want to put that extra work on you (I don't know much about that topic).

[janosh]

Very interested in this issue. Anything I can do to help?

[dominikg]

unfortunately jest doesn't really support esm, so a fallback to cjs is needed.

@dummdidumm would it be ok to require the cjs extension or fallback to require if import throws?

[dummdidumm]

Fine with me, if import() throws for real users later on there's not much you can do anyway. Error message might be confusing though, maybe the error message of the import() should be "saved" and thrown instead if require fails, too.

[dominikg]

released in 1.0.0-next.8

[dummdidumm]

I encountered a bug on windows. It tells me that the given path is not a valid scheme. Seeing that I remembered that I had the same issue in language-tools and what I did was wrapping the path with pathToFileUrl - sorry for not catching that earlier.

Also see nodejs/node#31710