What should be the canonical file extension for Svelte components?

extensions.md

So far, most of us have been writing Svelte components into .html files, with a few exceptions (Parcel users, for example, have additional constraints to work with). We're currently discussing whether this should change.

Once you've read the pros and cons, please vote!

.html

Pros:

• It signals that you can use your existing HTML (and CSS) knowledge
• Valid HTML is valid Svelte
• Syntax highlighting mostly works everywhere OOTB (expressions in {tags} are treated as text, though)

Cons:

• Svelte components aren't really HTML
• Tools like Parcel can't deal with it
• We don't get full syntax highlighting
• Some tools, like WebStorm, struggle with directives etc

.htmlx

Pros:

• It signals that it's HTML-with-extras
• Symmetry with .js and .jsx
• It's an invitation to other frameworks to collaborate, rather than continuously reinventing template languages

Cons:

• No syntax highlighting out of the box — imposes tooling requirements on users, could be offputting for new recruits
• It's a land grab
• May be hard to get Linguist to adopt Svelte syntax highlighting for it

.svelte

Pros:

• Does what it says on the tin. Zero ambiguity
• Linguist support — we should be able to claim svelte for fenced code blocks
• It's unlikely to cause conflict with other frameworks etc

Cons:

• No syntax highlighting. Like .htmlx, the first-time experience is poor

Why not have a short extension like "sve"?

.html will make it a lot harder for an ecosystem of tooling to be established.

.svelte is long and cumbersome for a file extension, imo. What about .sjs | .sts? It provides JavaScript and TypeScript flavoring opts. Alternatives: .svx, .sx

My vote: .sve. It's used as a binary data file for some old game, and should be easy to distinguish between text (Svelte) and binary (game data) files using .sve extension. Otherwise, the longer .svelte should be used.

Late on this thread, but would like to share my 2 cents.

HTML should definitely be a no go. HTML is a standard, any file with an .html extension is assumed to be a standards compliant. "Valid HTML is valid Svelte", sure, but it doesn't work the other way round. While Svelte is many things, in its current state it is not compliant with HTML. It could possibly be made SGML-compliant, anybody interested in writing the associated DTD?

IMHO html, htm, htmlx, and all similar extensions should be systematically and mechanically avoided.

I have only recently discovered Svelte and have become fond of it. I discovered this gist because I wanted to shorten the svelte extension and was seeking examples on GitHub. A three letter alternative, sve, svx, ... is fine for me. I would not make it an either or decision. svelte is the original extension and says it all... moreover I like that name :-) But for old timers like me who like symmetry everywhere, three letter extensions are a (maniac's) necessity.

A major reason for voting against .svelte or .s?? appears to be syntax highlighting, folding, and all the tra-la-la. This gist was initiated two years ago. I do assume the situation has significantly changed given that all the Svelte projects I have seen on GitHub so far use the .svelte extension (except one that used the .sve extension).

IMHO this is a false negative. I am a Vim user. It took me little more that 2 mn and 2 changes to modify an existing Svelte highlighting and al package to support both the .svelte and .sve extensions.

I too would like .sve

As someone who is dyslexic I would like to advocate for something that is shorter (and is more accessible) than .svelte. Preferably a collection of 3 or 4 acronym letters similar to .jsx or .tsx. Of which I can remember the order with out getting them muddled.

The only thing I don't like about svelte is the file extension which is saying ALOT. ANY three letter alternative would be much appreciated!

.svlt is a good name IMO. Ee simply remove the vowels but also maintain the pronunciation to be svelte.

.sv for easier typing. .s is possible but is clashing with assembly.