Allow named export instead of default export for components

[raythurnvoid]

Describe the problem

Today in order to use named export with .svelte components we have to create a separate .ts file and re-export the component and perhaps the type of the Props (just to import all stuff from the same module)

export { default as Heading100 } from './Heading100.svelte';
export type { Heading100Props } from './Heading100.svelte';

It's a little bit annoying, and it would be cool to have a more sveltish way of doing it, perhaps something like this:

<script lang="ts" named-export>

It would take the name of the file and export a symbol with the same value.

An alternative syntax can be:

<script lang="ts" export="MyComponent">

Another approach would be a configuration in the svelte.config.js.

Why?

It helps refactoring and code maintainability.

Let's say you want to deprecate a component and you want to change its name to something like MyComponentOld, it's frustrating that the component would still appear in the templates as <MyComponent /> and there's no way to do a global rename with refactoring tool, so the only option is text search and replace.

It helps maintainability because you ensure that in most of the cases the tag used in the templates matches the component name unless explicitly renamed with as, sometime unorganized devs write stuff like

import Button from '$lib/component/SparklingButton.svelte';
import Button2 from '$lib/components/BorderedButton.svelte';

Describe the proposed solution

Above

Importance

nice to have

[webJose]

I'm not openly against something like this. I just wonder about the reasons.

For deprecating: This should be mainly a concern for libraries, not projects. Projects don't share stuff with other projects, that's the job of libraries. In libraries, you usually export using named exports in the NPM package's index.js file. In projects, you just replace one component for another and you're done.

True, maybe it is better/more accurate to be able to do a "global rename" command, but I bet "Replace in files..." is almost as good.

Finally, trying to force a particular name on consumers is an opinion, and I believe it is Svelte's mission to be as unopinionated as possible. It is an opinion because it is not a performance hit, using as to rename is not a non-standard JavaScript feature, and is not a generally accepted bad practice, to the best of my knowledge.

Other than the above, I'd be OK with this, so long the default export is an option. I don't feel like changing it. If this is an opt-in feature, fine by me.

[Thiagolino8]

You can also re-export it from the script module

<script module>
  export {default as whatever} from './same-file.svelte'
</script>

[raythurnvoid]

Projects don't share stuff with other projects, that's the job of libraries. In libraries, you usually export using named exports in the NPM package's

@webJose My use case are just in projects, it happens that you need to create a v2 component to not cause regressions everywhere in the project

You can also re-export it from the script module

<context module>
  export {default as whatever} from './same-file.svelte'
</script>

@Thiagolino8 This is interesting, vscode auto-import may get a bit confusing since you don't know if you are importing the named or the default export.

[brunnerh]

I am also not a fan of default imports/exports.

If this feature is added it probably belongs in <svelte:options> and may require a value.

<svelte:options export="MyComponent" />

People use all sorts of file names (e.g. kebab-case.svelte) and while there is some algorithm implemented in the Svelte language tools that automatically turns them into PascalCase in the auto-imports, that conversion logic is not formally specified and it is probably better to be explicit anyway.

[dummdidumm]

This would change a fundamental part/contract that makes inherent sense as part of the single file components approach. It's not something we want to do for a relatively small gain, and the solution would only confuse people more I think. Therefore closing.