core-vapor
core-vapor copied to clipboard
vuejs
Defaults to TS for `<script vapor>`
Discussion: Should lang default to ts in Vapor SFCs?
<script vapor>
This would make it behave like a non-Vapor component:
<script setup lang="ts">
Please leave a 👍 or 👎 reaction below.
One of the vue main sell point is easy adoption. This would make it harder for junior. I don't mind keeping lang="ts" it's super easy with a snippet
It's worth mentioning that TS can essentially be considered a superset of JS. Enabling TS automatically does not require users to use types mandatorily. Astro also enables TypeScript by default.
Wouldn't it be a high cognitive load for users if the interface is not aligned with other modes?
In the case of Normal Mode, the default is setup="false" lang="js", and in the case of Vapor Mode, the default is setup="true" lang="ts", which seems a bit difficult to predict.
Some may argue that having documentation would solve the issue, but personally, I think predictability through a unified interface is important.
Astro also enables TypeScript by default.
If you want to default to TS, shouldn't we first raise an RFC in vuejs/core rather than here, so that vapor and non-vapor can be unified?
When marking Vapor Mode in the script attribute, I thought it would be better to have an interface like the following:
<script setup lang="ts" vapor>
</script>
Initially, there was a suggestion of using *.vapor.vue, but is it not necessary to first discuss whether it should be represented by attributes or file extensions? 🫠
- Because Vapor does not intend to support non-setup SFCs.
setupis also not a good name. Therefore, in Vapor, we decided to usevaporto replacesetup(not actually setting setup=true at the low level). - Regarding
*.vapor.vue, considering this will make the filename longer. It will also inevitably lengthen the import statements. Imagine an extreme caseApp.ce.vapor.client.vue. - Regarding the default enabling of TS in vuejs/core, this is a breaking change because there are slight inconsistencies between TS and JS, especially for JSX.
From my understanding, Vapor requires a build step to compile into runtime code. Given Vue works fantastically with TypeScript brings, I think a default of TS is sensible.
Because Vapor does not intend to support non-setup SFCs.
Shouldn't non-setup scripts be supported?
For example, I have seen projects that write code like the following (in fact, I often use it myself).
<!-- DialogA.vue -->
<script lang="ts">
export function useDialogA() {
/* ... */
return {/* ... */}
}
</script>
<script setup lang="ts">
// some setup script
</script>
<template>
<!-- ... -->
</template>
If non-setup scripts are not supported, we cannot export anything from the SFC.
About non-setup scripts, I haven't figured this out yet, let's leave this topic for another thread.
How about
<script> // options API
<script setup> // composition API
<script setup=vapor> // vapor mode
all defaults to lang=js
There may be two ways to indicate attributes, where to focus on them? (It's quite impromptu, I haven't thought deeply about it.)
<!-- If you want to focus on the attributes of the script as "SFC settings" -->
<script setup="vapor">
</script>
<template>
</template>
<!-- If you want to focus on the settings of the template (outputting a renderer that does not use virtual DOM) without affecting the setup -->
<script setup>
</script>
<template vapor>
</template>
In the latter case, the script remains the same as before.
Couldn't it be a compiler option that defaults to lang=js? Similar to having an option to enable vapor mode globally. It would pertain the same behavior while giving those who prefer lang=ts to set it globally with one line. This could be implemented for reglar setup too not just vapor
I think we should keep Vapor's behavior predictable. Replacing the setup attribute with the vapor attribute, to turn on Vapor Mode, would do it for most people 🙌🏼
<!-- Defaults to lang="js" as `setup` does -->
<script vapor>
</script>
<!-- Manually opt-in to TypeScript with lang="ts" keeping the same behaviour -->
<script vapor lang="ts">
</script>
Unless lang="ts" is a requirement for vapor mode, then it should not be the default.
I will also point out that this would be the only instance (I can think of) in a sfc where an attribute other than lang specifies what the compiler language is.
I have to echo what @icarusgk said, that script should default to JS.
<script lang="ts" vapor>
</script>
...is clear to me.
- Because Vapor does not intend to support non-setup SFCs.
setupis also not a good name. Therefore, in Vapor, we decided to usevaporto replacesetup(not actually setting setup=true at the low level).
If vapor will only work in setup mode, then the keyword setup can be replaced with it. Then if someone wants to use TS, they can decide to enable it.
I think we should keep Vapor's behavior predictable. Replacing the
setupattribute with thevaporattribute, to turn on Vapor Mode, would do it for most people 🙌🏼<!-- Defaults to lang="js" as `setup` does --> <script vapor> </script><!-- Manually opt-in to TypeScript with lang="ts" keeping the same behaviour --> <script vapor lang="ts"> </script>
This is the best suggestion. It's simple and straightforward.
We would like Vue users to use vapor as soon as possible. However, until it stabilises, we would like to be able to return to virtual DOM mode by simply removing the five letters vapor if a particular component does not work correctly in vapor mode.
Therefore, I would like to be able to write the following.
<script setup lang="ts" vapor>
</script>
For lang="js" / lang="ts", switching parsers based on language is very simple.
import * as acorn from 'acorn';
import { tsPlugin } from 'acorn-typescript';
const ParserWithTS = acorn.Parser.extend(tsPlugin({ allowSatisfies: true }));
const parser = typescript ? ParserWithTS : acorn.Parser;
If we don't support anything other than setup, we could simply throw an compile error if there is no setup in the <script>.
And for edge case:
If these is no script but want to use vapor mode,
then user need to add empty <script setup lang="ts" vapor></script> block.
(No need to do like <template vapor>)
pickup some tweets of vuejs team
@johnsoncodehk
https://x.com/johnsoncodehk/status/1787211286008213826
No... This will break Vue TmLanguage. https://github.com/vuejs/language-tools/blob/master/extensions/vscode/syntaxes/vue.tmLanguage.json
@Justineo
https://x.com/_justineo/status/1787305010654822788
I’d expect a vapor-compatible component to compile correctly if we remove the
vaporattribute.
I really like TypeScript, and I use it in almost all of my projects. However, the inconsistency between <script setup lang="ts"> and <script vapor> increases the mental burden during development.
I think enabling TS by default could be considered as a global configuration switch for a project, effective both in setup and vapor. This would avoid breaking changes while allowing projects that primarily use TypeScript to benefit from a more streamlined syntax.
At the same time, I also like the <template vapor> syntax because the vapor switch is mainly about modifying the template. (However, this might not be the main topic of this issue.)
I'd be happy to have a global config on this, and let individual component decides what they want.
I think the default ts would break the retrospective process. It makes the most sense;
How about
<script> // options API <script setup> // composition API <script setup=vapor> // vapor modeall defaults to
lang=js
I like this suggestion. Not ambiguous too. 👍🏾
My opinion aligns with @Ubugeeei on this. https://github.com/vuejs/core-vapor/issues/198#issuecomment-2094888400
I don't really mind making ts as default, but I think in that case, it should be so in non-vapor Vue SFC too 👀
TypeScript should not be the default for Vapor mode because it breaks the fundamental philosophy that Vue is an approachable framework.
In other words, we build on top of standards and let people opt in to what makes sense for their team. Regardless of people's opinions on whether TypeScript is superior, it has always been one of Vue's strengths to let people choose based on their opinion alone.
To enable TypeScript by default for Vapor (or non-vapor) would go against this fundamental philosophy that has made Vue the framework it is.
