-
-
Notifications
You must be signed in to change notification settings - Fork 205
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
Please make the svelte.config.js file available to esm users #519
Comments
Duplicate of #509 |
Why does using the CommonJS syntax in a config file unrelated to the rest of your project prevent you from using ESM syntax in the rest of your project? |
@dummdidumm svelte-vscode won't read the svelte.config.[ending] file if it has the |
|
sveltejs#519 To support `.cjs` configs
You should now be able to use |
Is your feature request related to a problem? Please describe.
ES Modules are the future, and many have realized this. NodeJS has introduced experimental esm support and popular players in open source are enforcing the use of them; for example, airbnb's widely known javascript style guide is already forbidding the use of non-standard module systems - this includes CommonJS.
To enable ESM support across my entire project, I set
"type": "module"
in mypackage.json
. Unfortunately, svelte-vscode expects that the svelte.config.js file is written in commonjs and attempts to require it, which breaks it for me and others using esm. Furthermore, svelte-vscode ignores the svelte config file if it has the.cjs
file ending, which is non standard-compliant behavior and leaves me no option to use the svelte language server/svelte-vscode.Describe the solution you'd like
ES Modules are the only true standard-conformant way of using modules, and even though they're in experimental support I haven't encountered any issues with using them. Please don't strictly
require()
the consumers config file (which might be written in esm and therefore cannot be required), but either infer the module system type from the file ending (.cjs
vs.mjs
) and import/require it based on that information or try to automatically detect the module system used.Describe alternatives you've considered
The alternative is to switch my whole project back to the commonjs default, but that would mean I would have to rewrite a lot of files back into commonjs and I'd loose all the nice features of esm. I shouldn't have to migrate my full project over for one config file that can only be read if it has a
.js
file ending in commonjs format. :/The text was updated successfully, but these errors were encountered: