Skip to content
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

Defaults to TS for <script vapor> #198

Open
sxzz opened this issue May 5, 2024 · 25 comments
Open

Defaults to TS for <script vapor> #198

sxzz opened this issue May 5, 2024 · 25 comments

Comments

@sxzz
Copy link
Member

sxzz commented May 5, 2024

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.

@unpseudocomplique
Copy link

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

@sxzz
Copy link
Member Author

sxzz commented May 5, 2024

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.

@ubugeeei
Copy link
Member

ubugeeei commented May 5, 2024

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? 🫠

@sxzz
Copy link
Member Author

sxzz commented May 5, 2024

  • Because Vapor does not intend to support non-setup SFCs. setup is also not a good name. Therefore, in Vapor, we decided to use vapor to replace setup (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 case App.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.

@RihanArfan
Copy link

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.

@ubugeeei
Copy link
Member

ubugeeei commented May 5, 2024

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.

@sxzz
Copy link
Member Author

sxzz commented May 5, 2024

About non-setup scripts, I haven't figured this out yet, let's leave this topic for another thread.

@pavi2410
Copy link

pavi2410 commented May 5, 2024

How about

<script> // options API
<script setup> // composition API
<script setup=vapor> // vapor mode

all defaults to lang=js

@ubugeeei
Copy link
Member

ubugeeei commented May 5, 2024

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.

@MuhammadM1998
Copy link

MuhammadM1998 commented May 5, 2024

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

@icarusgk
Copy link

icarusgk commented May 5, 2024

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>

@fimion
Copy link

fimion commented May 5, 2024

Unless lang="ts" is a requirement for vapor mode, then it should not be the default.

@fimion
Copy link

fimion commented May 5, 2024

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.

@michaelpumo
Copy link

michaelpumo commented May 6, 2024

I have to echo what @icarusgk said, that script should default to JS.

<script lang="ts" vapor>
</script>

...is clear to me.

@neneodonkor
Copy link

  • Because Vapor does not intend to support non-setup SFCs. setup is also not a good name. Therefore, in Vapor, we decided to use vapor to replace setup (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.

@neneodonkor
Copy link

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>

This is the best suggestion. It's simple and straightforward.

@baseballyama
Copy link

baseballyama commented May 6, 2024

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>)

@ubugeeei
Copy link
Member

ubugeeei commented May 6, 2024

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 vapor attribute.

@LittleSound
Copy link
Member

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.)

@eunjae-lee
Copy link
Contributor

I'd be happy to have a global config on this, and let individual component decides what they want.

@cyhnkckali
Copy link

I think the default ts would break the retrospective process. It makes the most sense;

<script setup vapor lang=‘ts’>

@neneodonkor
Copy link

How about

<script> // options API
<script setup> // composition API
<script setup=vapor> // vapor mode

all defaults to lang=js

I like this suggestion. Not ambiguous too. 👍🏾

@suisuiz
Copy link

suisuiz commented May 7, 2024

I think TS should not be the default.

@kiaking
Copy link
Member

kiaking commented May 7, 2024

My opinion aligns with @ubugeeei on this.
#198 (comment)

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 👀

@bencodezen
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests