[Proposal]: New `.fusion` suffix for template files

[ace-of-aces]

Hi Aaron and contributors, congrats on the open source release! 🎉

I am proposing a new .fusion suffix/identifier (like in Blade) for Fusion template files that would do the following:

Component.vue -> Component.fusion.vue

This might have several benefits:

1. Clear separation: It would make it much more obvious that you are not dealing with a standard Vue SFC (or JSX in the future), but with Fusion as a superset of it.
2. LSP Support: A prefix might make it easier for future IDE Helpers/Plugins/LSPs to discover and efficiently provide syntax highlighting, and vice versa, for other Vue/JSX-only LSPs to exclude these.
3. Consistency with Blade: For Laravel devs who are used to .blade.php and seeing a Fusion codebase with .fusion.vue for the first time, this might make it easy to understand what Fusion is.
4. File Explorer Icons: This might be a detail, but it would make it possible for VSCode/PHPStorm to show a custom icon for template files using Fusion, just like Blade in PHPStorm.

From a quick Google search, I haven’t seen anything in the Vue/React ecosystem using such prefix yet, so this (hopefully) wouldn’t break any existing software. A small test in VSCode and PHPStorm didn’t break anything for me.

Maybe this could also be made configurable/optional via Vite plugin options (like in https://github.com/vitejs/vite-plugin-vue/tree/main/packages/plugin-vue#options)?

Some of this is based on assumptions tho, as I’m not an extension developer (yet), but I'm encouraged by your “I’m not qualified to do this” quote from Laracon EU :)

I'd be happy to create a PR and hear your opinion on this!

[Barbapapazes]

LSP Support: A prefix might make it easier for future IDE Helpers/Plugins/LSPs to discover and efficiently provide syntax highlighting, and vice versa, for other Vue/JSX-only LSPs to exclude these.

It can help in a sens that you could avoid to start a LSP server if there is no .fusion.vue but that's it. Actually, a tool like Volar (or Vue Language Tool) works well with JavaScript, TypeScript, HTML and CSS, all in the same file. Also, I successfully develop an extension to provide syntax highlightning in VSCode. (fusion-vscode)

But I agree for all other points!

[ace-of-aces]

@Barbapapazes Alright, thanks for the insight, that totally makes sense!
Does the extension impact VSCode's performance/resource consumption when working on other Vue projects that are not using Fusion, or is this negligible?
I'll try out your extension right away.

[deanmcpherson]

Something like this will likely be more needed for the react ecosystem, which doesn't conceptually have sfc's

I suppose you could define as a global tsx element, but imo if the changes make it invalid standard .vue or .tsx files, then it should have a prefix or custom file extension

The closest solution for react I've found that doesn't require custom tooling is to use tagged template literals. There's vscode extensions for syntax highlighting, and opening the template contents in side tabs

It's still pretty average as an experience though

[darkylmnx]

I don't think it's a good idea, and will actually make things more confusing in the future for the following reasons:

1. your suggestion is about comfort for Laravel users because, I quote "who are used to .blade.php", but Fusion is probably going to evolve to be agnostic as Inertia is, so comfort for a specific group of user is not futur-prooft
2. Livewire volt is basically what Fusion is as a paradigme, but we (in the Laravel community) never had .volt extension or anything, despite volt not being a classic blade file at all, but a superset as Fusion is in .vue files, so even for consistency towards this here, not having any extension makes more sens, it could be a convention for those who want it, but shouldn't be forced or have any impact on your code or editor, same goes for icons
3. For React what will probably happen is using template literals, because that's how css-in-js is handled, that's how pug is handled, that's actually THE React-way to introduce now things, same goes for React compatible stuff like Preact.

Overall, I don't think an enforced extension brings more clarity, bug actually brings unecessary rules to something that isn't actually a new file format, but just an addition to an existing format.

[ace-of-aces]

@darkylmnx Thanks, I think I get your point. I guess it's a matter of whether you want an opinionated project structure or not.
For the performance part, I was only worried that not having a more clear separation would impact your editor performance, because perhaps a PHP LSP would have to be spun up on every Vue file, whether it uses it or not, but it doesn't seem like that's an issue.
I thought of the Vue implementation as breaking the original format, as a component using the tag is not valid Vue by default and does not compile without the Fusion Vite plugin. With a React implementation using template literals, this wouldn't be breaking JSX standards as far as I'm concerned.

[darkylmnx]

@ace-of-aces performance wise, AFAiK, it's not going to be worst than when you have other custom tags.

Vue has a lot of custom tags or attributes, like for scss, CSS modules, i81n tag, pug lang...

For all these there are different kind of loaders and interpreters so I guess it's should be fine.

At least I feel like doing this for fusion opens the door to everything not being native Vue tags, which is already the case of a lot of plugins like the i18n tag.

[ace-of-aces]

@darkylmnx Yeah, I just read the SFC specification, especially custom tags. So as Fusion is not breaking the spec, and the same goes for React/JSX, I guess it only comes down to DX considerations.

[ace-of-aces]

So, as I've generally heard more concerns than support for this proposal from you guys, do you think I should close this issue?

[TechAkayy]

I would suggest not using a .fusion.vue suffix, rather use .fusion and have a way to automatically consider it as a .vue or .tsx, if fusion is going to be framework agnostic in the long run. Whether language tools can extend support to .fusion could be explored. This will clearly distinguish between fusion vs non-fusion files in the project structure.

Vite config could take a param to default the .fusion to be considered as .vue, .svelte or .astro etc. In fact, iles does something like this to consider.jsx/.tsx files either as vue, solid or preact components in the build chain.

I always wished astro did this way, instead they introduced a completely new component spec with its own jsx-html hybrid syntaxes, instead of using a battle-test well-established component spec like Vue SFCs or follow my above suggestion for.fusion (auto-framework detection).