From 96c72ff90e91dbbdba2e587c33fd0cc5b3ad2d32 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Mon, 29 Jun 2020 15:57:59 -0400
Subject: [PATCH 01/14] sfc improvements

---
 active-rfcs/0000-sfc-component-sugar.md | 128 +++++++++++
 active-rfcs/0000-sfc-script-setup.md    | 278 ++++++++++++++++++++++++
 active-rfcs/0000-sfc-style-variables.md |  82 +++++++
 3 files changed, 488 insertions(+)
 create mode 100644 active-rfcs/0000-sfc-component-sugar.md
 create mode 100644 active-rfcs/0000-sfc-script-setup.md
 create mode 100644 active-rfcs/0000-sfc-style-variables.md

diff --git a/active-rfcs/0000-sfc-component-sugar.md b/active-rfcs/0000-sfc-component-sugar.md
new file mode 100644
index 00000000..ebafc46b
--- /dev/null
+++ b/active-rfcs/0000-sfc-component-sugar.md
@@ -0,0 +1,128 @@
+- Start Date: 2020-06-29
+- Target Major Version: 2.x & 3.x
+- Reference Issues: N/A
+- Implementation PR: N/A
+
+# Summary
+
+Syntax sugar for reducing component import and registration boilerplate in Single File Components.
+
+# Basic example
+
+```html
+<component src="./Foo.vue"/>
+
+<template>
+  <Foo/>
+</template>
+```
+
+# Motivation
+
+Currently in SFCs you have to import a component and then pass it to the `export default { components: { ... } }` hash, which leads to a lot of redundancy: for a single component we are repeating its name 3 times: in the imported binding, the file name, and the components option.
+
+The `<component/>` sugar requires the name of each component to be specified only once.
+
+# Detailed design
+
+## Normal Components
+
+**Before**
+
+```html
+<template>
+  <Foo/>
+</template>
+
+<script>
+import Foo from './Foo.vue'
+
+export default {
+  components: {
+    Foo
+  }
+}
+</script>
+```
+
+**After**
+
+```html
+<component src="./Foo.vue"/>
+
+<template>
+  <Foo/>
+</template>
+```
+
+## Async Components
+
+**Before**
+
+```html
+<template>
+  <Foo/>
+</template>
+
+<script>
+import { defineAsyncComponent } from 'vue'
+
+export default {
+  components: {
+    Foo: defineAsyncComponent(() => import('./Foo.vue'))
+  }
+}
+</script>
+```
+
+**After**
+
+```html
+<component async src="./Foo.vue" />
+
+<template>
+  <Foo/>
+</template>
+```
+
+## Component Renaming
+
+By default, the component's locally registered name is inferred from its filename. But they can be renamed locally:
+
+```html
+<component src="./Foo.vue" as="Bar" />
+
+<template>
+  <Bar/>
+</template>
+```
+
+# Drawbacks
+
+This would require updates in tools that parse SFC content for template analysis - e.g. Vetur & `@vuedx`.
+
+However, since this information is going to be provided directly by `@vue/compiler-sfc` in the parsed SFC descriptor, it should remove some extra complexity from these tools as well.
+
+# Alternatives
+
+We considered implicitly registering imported components:
+
+```html
+<template>
+  <Foo/>
+</template>
+
+<script>
+import Foo from './Foo.vue'
+</script>
+```
+
+However, this approach has a few issues:
+
+- `Foo` is unused in the script scope, making it annoying when using linter rules that check for unused variables.
+
+- The only safe assumption about an import being a Vue component is the `.vue` extension, which makes it unable to support components authored in non-SFC formats (e.g. `import Foo from './Foo/ts'` can be a component but we can't really be sure).
+
+# Adoption strategy
+
+This is a fully backwards compatible new feature. However, we probably want to warn users against mixing the manual imports and `<component>` tags so that tools that rely on the extracted information can make safer assumptions.
diff --git a/active-rfcs/0000-sfc-script-setup.md b/active-rfcs/0000-sfc-script-setup.md
new file mode 100644
index 00000000..5f4acd01
--- /dev/null
+++ b/active-rfcs/0000-sfc-script-setup.md
@@ -0,0 +1,278 @@
+- Start Date: 2020-06-29
+- Target Major Version: 2.x & 3.x
+- Reference Issues: N/A
+- Implementation PR: N/A
+
+# Summary
+
+Introduce a compile step for `<script setup>` to improve the authoring experience when using the Composition API inside Single File Components.
+
+# Basic example
+
+```html
+<template>
+  <button @click="inc">{{ count }}</button>
+</template>
+
+<script setup>
+import { ref } from 'vue'
+
+export const count = ref(0)
+export const inc = () => count.value++
+</script>
+```
+
+# Motivation
+
+When authoring components using the Composition API, very often `setup` is the only option that's being used. This results in some unnecessary boilerplate:
+
+```js
+import { ref } from 'vue'
+
+export default {
+  setup() {
+    const count = ref(0)
+    const inc = () => count.value++
+
+    return {
+      count,
+      inc
+    }
+  }
+}
+```
+
+In addition, one of the most often complained about aspect of the Composition API is the necessity to repeat all the bindings that need to be exposed to the render context using a return object.
+
+This RFC introduces a compiler-powered alternative for the usage of `<script>` inside SFCs that greatly reduces the amount of boilerplate:
+
+```diff
+import { ref } from 'vue'
+
+-export default {
+-  setup() {
+-    const count = ref(0)
++export const count = ref(0)
+-    const inc = () => count.value++
++export const inc = () => count.value++
+
+-    return {
+-      count,
+-      inc
+-    }
+-  }
+-}
+```
+
+# Detailed design
+
+When a `<script>` tag in an SFC has the `setup` attribute, it is compiled so that the code runs in the context of the `setup()` function of the component. All ES module exports are considered values to be exposed to the render context and included in the `setup()` return object.
+
+## Using `setup()` arguments
+
+The following equivalent of `setup()` arguments are implicitly available inside `<script setup>`:
+
+- `$props`
+- `$attrs`
+- `$slots`
+- `$emit`
+
+The example code
+
+```js
+import { watchEffect } from 'vue'
+
+watchEffect(() => console.log($props.msg))
+$emit('foo')
+```
+
+would be compiled into:
+
+```js
+import { watchEffect } from 'vue'
+
+export default {
+  setup($props, { emit: $emit }) {
+    watchEffect(() => console.log($props.msg))
+    $emit('foo')
+    return {}
+  }
+}
+```
+
+## Declaring props or additional options
+
+One problem with `<script setup>` is that it removes the ability to declare other component options, for example `props`. We can solve this by checking a special export, `$options`:
+
+```vue
+<script setup>
+import { computed } from 'vue'
+
+export const $options = {
+  props: {
+    msg: String
+  }
+}
+
+export const computedMsg = computed(() => $props.msg + '!!!')
+</script>
+```
+
+This will compile to:
+
+```js
+import { computed } from 'vue'
+
+const $options = {
+  props: {
+    msg: String
+  },
+  inheritAttrs: false
+}
+
+export default {
+  ...$options,
+  setup($props) {
+    const computedMsg = computed(() => $props.msg + '!!!')
+
+    return {
+      computedMsg
+    }
+  }
+}
+```
+
+## With TypeScript
+
+`<script setup>` should just work with TypeScript in most cases. To make implicitly injected variables like `$props` and `$emit` work with proper types, simply declare them:
+
+```vue
+<script setup lang="ts">
+import { computed } from 'vue'
+
+// declare props using TypeScript syntax
+// this will be auto compiled into runtime equivalent!
+declare const $props: {
+  msg: string
+}
+
+export const computedMsg = computed(() => $props.msg + '!!!')
+</script>
+```
+
+The above will compile to:
+
+```vue
+<script lang="ts">
+import { computed, defineComponent } from 'vue'
+
+type __$props__ = { msg: string }
+
+export default defineComponent({
+  props: (['msg'] as unknown) as undefined,
+  setup($props: props__) {
+    const computedMsg = computed(() => $props.msg + '!!!')
+
+    return {
+      computedMsg
+    }
+  }
+})
+</script>
+```
+
+- Runtime props declaration is automatically generated from TS typing to remove the need of double declaration and still ensure correct runtime behavior. (It is force casted into `undefined` to ensure the user provided type is used in the emitted code)
+
+- The emitted code is still TypeScript with valid typing, which can be further processed by other tools.
+
+# Drawbacks
+
+This is yet another way of authoring components, and it requires understanding the Composition API first.
+
+# Adoption strategy
+
+This is a fully backwards compatible new feature.
+
+
+# Unresolved Questions
+
+## Magic `let` bindings
+
+It is technically possible to compile `let` bindings in a way so that root level `let` bindings are implicitly reactive:
+
+```vue
+<script setup>
+export let count = 0
+
+export function increment() {
+  count++
+}
+</script>
+```
+
+can be compiled into:
+
+```vue
+<script>
+import { reactive } from 'vue'
+
+export default {
+  setup() {
+    const __ctx__ = shallowReactive({})
+    __ctx__.count = 0
+
+    function increment() {
+      __ctx__.count++
+    }
+
+    return Object.assign(__ctx__, {
+      increment
+    })
+  }
+}
+</script>
+```
+
+This makes the code even more succinct and removes the need to use `ref` in the root scope of the component. However, this may be a bit too magical and there are a number of consistency issues if we enable this behavior:
+
+- Objects are not implicitly reactive:
+
+  ```js
+  export const state = { count: 0 }
+
+  export function increment() {
+    // doesn't work
+    state.count++
+  }
+  ```
+
+  Making root scope objects deeply reactive by default can lead to potential performance problems, since the user may declare a 3rd party object of unknown size.
+
+- Doesn't work inside nested functions:
+
+  ```js
+  function useFeature() {
+    // not reactive, since it's not root level
+    let count = 1
+    const inc = () => count++
+
+    return {
+      count,
+      inc
+    }
+  }
+  ```
+
+  If we also compile functions inside `<script setup>`, then composition functions inside and outside SFCs will behave *very* differently and the mental model is no longer consistent. It also creates friction for extracting reusable functions out of components.
+
+- Dependency tracking no longer explicit:
+
+  ```js
+  export let count = 0
+
+  watchEffect(() => console.log(count))
+  ```
+
+  By looking at the `watchEffect` callback alone, it is not immediately clear whether it tracks any dependencies at all. We will now need to check if a variable is declared via root level `let` to be sure.
+
+Given the above considerations, magical `let` bindings is not a part of the proposed features of this RFC, but it's discussed here to provide context on why we chose not to include it.
diff --git a/active-rfcs/0000-sfc-style-variables.md b/active-rfcs/0000-sfc-style-variables.md
new file mode 100644
index 00000000..2519ec72
--- /dev/null
+++ b/active-rfcs/0000-sfc-style-variables.md
@@ -0,0 +1,82 @@
+- Start Date: 2020-06-29
+- Target Major Version: 2.x & 3.x
+- Reference Issues: N/A
+- Implementation PR: N/A
+
+# Summary
+
+Support injecting component-state-driven CSS variables into Single File Components styles.
+
+# Basic example
+
+```html
+<template>
+  <div class="text">hello</div>
+</template>
+
+<script>
+export default {
+  data() {
+    return {
+      color: 'red'
+    }
+  }
+}
+</script>
+
+<style :vars="{ color }">
+.text {
+  color: var(--color);
+}
+</style>
+```
+
+# Motivation
+
+Vue SFC styles provide straightforward CSS collocation and encapsulation, but it is purely static - which means up to this point we have no capability of dynamically updating the styles at runtime based on the component's state.
+
+Now with [most modern browsers supporting native CSS variables](https://caniuse.com/#feat=css-variables), we can leverage it to easily connect the component's state and styles.
+
+# Detailed design
+
+The `<style>` tag in an SFC now supports a `:vars` binding, which accepts an expression for the key/values to inject as CSS variables. The expression must be an object literal and cannot contain computed keys (the compiler will warn such cases - see reasoning in the next section). Other than that, it is evaluated in the same context as expressions inside `<template>`.
+
+The variables will be applied to the component's root element as inline styles. In the above example, given a `:vars` binding that evaluates to `{ color: 'red' }`, the rendered HTML will be:
+
+```html
+<div style="--color:red" class="text">hello</div>
+```
+
+## Usage with `<style scoped>`
+
+When `:vars` is used with `<style scoped>`, we need to make sure the CSS variables do not leak to descendent components or accidentally shadow CSS variables higher up the DOM tree. The applied CSS variables will be prefixed with the component's scope ID:
+
+```html
+<div style="--v-6b53742-color:red" class="text">hello</div>
+```
+
+Similarly, CSS variables inside `<style>` that matches the keys in the `:vars` expression will also be rewritten accordingly. This is also why we require the `:vars` expression to be an object literal with no computed keys.
+
+# Alternatives
+
+## Auto Detect Variables
+
+One of the considered alternatives is auto detecting variables to inject using a naming convention:
+
+```html
+<style>
+.text {
+  color: var(--v-color);
+}
+</style>
+```
+
+However, this has a few disadvantages:
+
+- Intention is less explicit;
+
+- Requires a full PostCSS parse first to extract matching variables before the main script can be processed. With `:vars` being declared on the `<style>` tag, the compiler can process the `<script>` part without parsing the CSS at all.
+
+# Adoption strategy
+
+This is a fully backwards compatible new feature. However, we should make it clear that it relies on native CSS variables so the user needs to be aware of the browser support range.

From 390e0a2076ed5054aff4fc259579643d0c6d0891 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Mon, 29 Jun 2020 16:11:38 -0400
Subject: [PATCH 02/14] improve component sugar example

---
 active-rfcs/0000-sfc-component-sugar.md | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/active-rfcs/0000-sfc-component-sugar.md b/active-rfcs/0000-sfc-component-sugar.md
index ebafc46b..59b6beb8 100644
--- a/active-rfcs/0000-sfc-component-sugar.md
+++ b/active-rfcs/0000-sfc-component-sugar.md
@@ -11,9 +11,13 @@ Syntax sugar for reducing component import and registration boilerplate in Singl
 
 ```html
 <component src="./Foo.vue"/>
+<component async src="./Bar.vue"/>
+<component src="./Baz.vue" as="Qux" />
 
 <template>
   <Foo/>
+  <Bar/>
+  <Qux/>
 </template>
 ```
 

From 22bfdc8b638298eb81286df1e1b10089110f40eb Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Mon, 29 Jun 2020 16:29:12 -0400
Subject: [PATCH 03/14] fix example consistency

---
 active-rfcs/0000-sfc-script-setup.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/active-rfcs/0000-sfc-script-setup.md b/active-rfcs/0000-sfc-script-setup.md
index 5f4acd01..a7b2ab69 100644
--- a/active-rfcs/0000-sfc-script-setup.md
+++ b/active-rfcs/0000-sfc-script-setup.md
@@ -111,7 +111,8 @@ import { computed } from 'vue'
 export const $options = {
   props: {
     msg: String
-  }
+  },
+  inheritAttrs: false
 }
 
 export const computedMsg = computed(() => $props.msg + '!!!')

From d805c9ba8ef38cc8d45f7c0a4481b34e1a97b22d Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Mon, 29 Jun 2020 16:47:36 -0400
Subject: [PATCH 04/14] fix example

---
 active-rfcs/0000-sfc-script-setup.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/active-rfcs/0000-sfc-script-setup.md b/active-rfcs/0000-sfc-script-setup.md
index a7b2ab69..2a147d7c 100644
--- a/active-rfcs/0000-sfc-script-setup.md
+++ b/active-rfcs/0000-sfc-script-setup.md
@@ -171,7 +171,7 @@ type __$props__ = { msg: string }
 
 export default defineComponent({
   props: (['msg'] as unknown) as undefined,
-  setup($props: props__) {
+  setup($props: __$props__) {
     const computedMsg = computed(() => $props.msg + '!!!')
 
     return {

From 2d94fbf144e4f68b46506b8e364984b830bfb07a Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Mon, 29 Jun 2020 16:50:31 -0400
Subject: [PATCH 05/14] fix typo

---
 active-rfcs/0000-sfc-component-sugar.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/active-rfcs/0000-sfc-component-sugar.md b/active-rfcs/0000-sfc-component-sugar.md
index 59b6beb8..2fe0b737 100644
--- a/active-rfcs/0000-sfc-component-sugar.md
+++ b/active-rfcs/0000-sfc-component-sugar.md
@@ -125,7 +125,7 @@ However, this approach has a few issues:
 
 - `Foo` is unused in the script scope, making it annoying when using linter rules that check for unused variables.
 
-- The only safe assumption about an import being a Vue component is the `.vue` extension, which makes it unable to support components authored in non-SFC formats (e.g. `import Foo from './Foo/ts'` can be a component but we can't really be sure).
+- The only safe assumption about an import being a Vue component is the `.vue` extension, which makes it unable to support components authored in non-SFC formats (e.g. `import Foo from './Foo.ts'` can be a component but we can't really be sure).
 
 # Adoption strategy
 

From 391a10c1c709dddd0f150d942c187f9bbb7fe9ed Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Tue, 30 Jun 2020 12:41:19 -0400
Subject: [PATCH 06/14] make it clear let bindings are not part of the RFC

---
 active-rfcs/0000-sfc-script-setup.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/active-rfcs/0000-sfc-script-setup.md b/active-rfcs/0000-sfc-script-setup.md
index 2a147d7c..89e465f8 100644
--- a/active-rfcs/0000-sfc-script-setup.md
+++ b/active-rfcs/0000-sfc-script-setup.md
@@ -199,6 +199,8 @@ This is a fully backwards compatible new feature.
 
 ## Magic `let` bindings
 
+> Note: This section is not a part of this RFC but included here merely for reference.
+
 It is technically possible to compile `let` bindings in a way so that root level `let` bindings are implicitly reactive:
 
 ```vue

From 923348ce72fd96fe8801f78357e4d57bf176fd78 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Tue, 30 Jun 2020 12:46:54 -0400
Subject: [PATCH 07/14] use export default for options

---
 active-rfcs/0000-sfc-script-setup.md | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/active-rfcs/0000-sfc-script-setup.md b/active-rfcs/0000-sfc-script-setup.md
index 89e465f8..4f68e98f 100644
--- a/active-rfcs/0000-sfc-script-setup.md
+++ b/active-rfcs/0000-sfc-script-setup.md
@@ -102,13 +102,13 @@ export default {
 
 ## Declaring props or additional options
 
-One problem with `<script setup>` is that it removes the ability to declare other component options, for example `props`. We can solve this by checking a special export, `$options`:
+One problem with `<script setup>` is that it removes the ability to declare other component options, for example `props`. We can solve this by treating the default export as additional options (this also aligns with normal `<script>`):
 
 ```vue
 <script setup>
 import { computed } from 'vue'
 
-export const $options = {
+export default {
   props: {
     msg: String
   },
@@ -124,15 +124,11 @@ This will compile to:
 ```js
 import { computed } from 'vue'
 
-const $options = {
+export default {
   props: {
     msg: String
   },
-  inheritAttrs: false
-}
-
-export default {
-  ...$options,
+  inheritAttrs: false,
   setup($props) {
     const computedMsg = computed(() => $props.msg + '!!!')
 

From b1c7267cd67440ba1db5f9e477c205a9685397dc Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Fri, 17 Jul 2020 15:05:59 -0400
Subject: [PATCH 08/14] update `<script setup>` details + require setup
 signature via attribute value

---
 active-rfcs/0000-sfc-script-setup.md | 181 ++++++++++++---------------
 1 file changed, 78 insertions(+), 103 deletions(-)

diff --git a/active-rfcs/0000-sfc-script-setup.md b/active-rfcs/0000-sfc-script-setup.md
index 4f68e98f..c6fb46e1 100644
--- a/active-rfcs/0000-sfc-script-setup.md
+++ b/active-rfcs/0000-sfc-script-setup.md
@@ -15,10 +15,10 @@ Introduce a compile step for `<script setup>` to improve the authoring experienc
 </template>
 
 <script setup>
-import { ref } from 'vue'
+  import { ref } from 'vue'
 
-export const count = ref(0)
-export const inc = () => count.value++
+  export const count = ref(0)
+  export const inc = () => count.value++
 </script>
 ```
 
@@ -36,9 +36,9 @@ export default {
 
     return {
       count,
-      inc
+      inc,
     }
-  }
+  },
 }
 ```
 
@@ -70,33 +70,31 @@ When a `<script>` tag in an SFC has the `setup` attribute, it is compiled so tha
 
 ## Using `setup()` arguments
 
-The following equivalent of `setup()` arguments are implicitly available inside `<script setup>`:
-
-- `$props`
-- `$attrs`
-- `$slots`
-- `$emit`
+Setup arguments can be specified as the value of the `setup` attribute:
 
-The example code
-
-```js
+```vue
+<script setup="props, { emit }">
 import { watchEffect } from 'vue'
 
-watchEffect(() => console.log($props.msg))
-$emit('foo')
+watchEffect(() => console.log(props.msg))
+emit('foo')
+</script>
 ```
 
-would be compiled into:
+will be compiled into:
 
 ```js
 import { watchEffect } from 'vue'
 
+// setup is exported as a named export so it can be imported and tested
+export function setup(props, { emit }) {
+  watchEffect(() => console.log(props.msg))
+  emit('foo')
+  return {}
+}
+
 export default {
-  setup($props, { emit: $emit }) {
-    watchEffect(() => console.log($props.msg))
-    $emit('foo')
-    return {}
-  }
+  setup,
 }
 ```
 
@@ -105,17 +103,17 @@ export default {
 One problem with `<script setup>` is that it removes the ability to declare other component options, for example `props`. We can solve this by treating the default export as additional options (this also aligns with normal `<script>`):
 
 ```vue
-<script setup>
+<script setup="props">
 import { computed } from 'vue'
 
 export default {
   props: {
-    msg: String
+    msg: String,
   },
-  inheritAttrs: false
+  inheritAttrs: false,
 }
 
-export const computedMsg = computed(() => $props.msg + '!!!')
+export const computedMsg = computed(() => props.msg + '!!!')
 </script>
 ```
 
@@ -124,21 +122,27 @@ This will compile to:
 ```js
 import { computed } from 'vue'
 
-export default {
+const __default__ = {
   props: {
-    msg: String
+    msg: String,
   },
   inheritAttrs: false,
-  setup($props) {
-    const computedMsg = computed(() => $props.msg + '!!!')
+}
 
-    return {
-      computedMsg
-    }
+export function setup(props) {
+  const computedMsg = computed(() => props.msg + '!!!')
+
+  return {
+    computedMsg,
   }
 }
+
+__default__.setup = setup
+export default __default__
 ```
 
+Since `export default` is hoisted outside of `setup()`, it cannot reference variables declared inside. For example, if the default export object references `computedMsg`, it will result in a compile-time error.
+
 ## With TypeScript
 
 `<script setup>` should just work with TypeScript in most cases. To make implicitly injected variables like `$props` and `$emit` work with proper types, simply declare them:
@@ -166,112 +170,83 @@ import { computed, defineComponent } from 'vue'
 type __$props__ = { msg: string }
 
 export default defineComponent({
-  props: (['msg'] as unknown) as undefined,
+  props: ({
+    msg: String
+  } as unknown) as undefined,
   setup($props: __$props__) {
     const computedMsg = computed(() => $props.msg + '!!!')
 
     return {
-      computedMsg
+      computedMsg,
     }
-  }
+  },
 })
 </script>
 ```
 
-- Runtime props declaration is automatically generated from TS typing to remove the need of double declaration and still ensure correct runtime behavior. (It is force casted into `undefined` to ensure the user provided type is used in the emitted code)
-
-- The emitted code is still TypeScript with valid typing, which can be further processed by other tools.
+- Runtime props declaration is automatically generated from TS typing to remove the need of double declaration and still ensure correct runtime behavior.
 
-# Drawbacks
+  - In dev mode, the compiler will try to infer corresponding runtime validation from the types. For example here `msg: String` is inferred from the `msg: string` type.
 
-This is yet another way of authoring components, and it requires understanding the Composition API first.
+  - In prod mode, the compiler will generate the array format declaration to reduce bundle size (the props here will be compiled into `['msg']`)
 
-# Adoption strategy
+  - The generated props declaration is force casted into `undefined` to ensure the user provided type is used in the emitted code.
 
-This is a fully backwards compatible new feature.
+- The emitted code is still TypeScript with valid typing, which can be further processed by other tools.
 
 
-# Unresolved Questions
+## Usage alongside normal `<script>`
 
-## Magic `let` bindings
+There are some cases where the code must be executed in the module scope, for example:
 
-> Note: This section is not a part of this RFC but included here merely for reference.
+- Declaring named exports that can be imported from the SFC file (`import { named } from './Foo.vue'`)
 
-It is technically possible to compile `let` bindings in a way so that root level `let` bindings are implicitly reactive:
+- Global side effects that should only execute once.
 
-```vue
-<script setup>
-export let count = 0
-
-export function increment() {
-  count++
-}
-</script>
-```
-
-can be compiled into:
+In such cases, a normal `<script>` block can be used alongside `<script setup>`:
 
 ```vue
 <script>
-import { reactive } from 'vue'
+performGlobalSideEffect()
 
-export default {
-  setup() {
-    const __ctx__ = shallowReactive({})
-    __ctx__.count = 0
+// this can be imported as `import { named } from './*.vue'`
+export const named = 1
+</script>
 
-    function increment() {
-      __ctx__.count++
-    }
+<script setup>
+import { ref } from 'vue'
 
-    return Object.assign(__ctx__, {
-      increment
-    })
-  }
-}
+export const count = ref(0)
 </script>
 ```
 
-This makes the code even more succinct and removes the need to use `ref` in the root scope of the component. However, this may be a bit too magical and there are a number of consistency issues if we enable this behavior:
+the above will compile to:
 
-- Objects are not implicitly reactive:
-
-  ```js
-  export const state = { count: 0 }
-
-  export function increment() {
-    // doesn't work
-    state.count++
-  }
-  ```
-
-  Making root scope objects deeply reactive by default can lead to potential performance problems, since the user may declare a 3rd party object of unknown size.
+```js
+import { ref } from 'vue'
 
-- Doesn't work inside nested functions:
+performGlobalSideEffect()
 
-  ```js
-  function useFeature() {
-    // not reactive, since it's not root level
-    let count = 1
-    const inc = () => count++
+export const named = 1
 
-    return {
-      count,
-      inc
-    }
+export function setup() {
+  const count = ref(0)
+  return {
+    count
   }
-  ```
+}
+
+export default { setup }
+```
 
-  If we also compile functions inside `<script setup>`, then composition functions inside and outside SFCs will behave *very* differently and the mental model is no longer consistent. It also creates friction for extracting reusable functions out of components.
+## Usage Restrictions
 
-- Dependency tracking no longer explicit:
+Due to the difference in module execution semantics, code inside `<script setup>` relies on the context of an SFC. When moved into external `.js` or `.ts` files, it may lead to confusions for both developers and tools. Therefore, **`<script setup>`** cannot be used with the `src` attribute.
 
-  ```js
-  export let count = 0
+# Drawbacks
 
-  watchEffect(() => console.log(count))
-  ```
+This is yet another way of authoring components, and it requires understanding the Composition API first.
 
-  By looking at the `watchEffect` callback alone, it is not immediately clear whether it tracks any dependencies at all. We will now need to check if a variable is declared via root level `let` to be sure.
+# Adoption strategy
 
-Given the above considerations, magical `let` bindings is not a part of the proposed features of this RFC, but it's discussed here to provide context on why we chose not to include it.
+This is a fully backwards compatible new feature.

From 3a2b0e7e03febd0bb66745d66593119a6ced23d9 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Fri, 17 Jul 2020 15:07:38 -0400
Subject: [PATCH 09/14] update `<style vars>` proposal

- use `vars` instead of `:vars`
- default all variables to local in scoped + vars mode
- remove expression syntax restrictions
---
 active-rfcs/0000-sfc-style-variables.md | 48 +++++++++++++++++--------
 1 file changed, 33 insertions(+), 15 deletions(-)

diff --git a/active-rfcs/0000-sfc-style-variables.md b/active-rfcs/0000-sfc-style-variables.md
index 2519ec72..c68bcaa9 100644
--- a/active-rfcs/0000-sfc-style-variables.md
+++ b/active-rfcs/0000-sfc-style-variables.md
@@ -24,7 +24,7 @@ export default {
 }
 </script>
 
-<style :vars="{ color }">
+<style vars="{ color }">
 .text {
   color: var(--color);
 }
@@ -39,9 +39,9 @@ Now with [most modern browsers supporting native CSS variables](https://caniuse.
 
 # Detailed design
 
-The `<style>` tag in an SFC now supports a `:vars` binding, which accepts an expression for the key/values to inject as CSS variables. The expression must be an object literal and cannot contain computed keys (the compiler will warn such cases - see reasoning in the next section). Other than that, it is evaluated in the same context as expressions inside `<template>`.
+The `<style>` tag in an SFC now supports a `vars` binding, which accepts an expression for the key/values to inject as CSS variables. It is evaluated in the same context as expressions inside `<template>`.
 
-The variables will be applied to the component's root element as inline styles. In the above example, given a `:vars` binding that evaluates to `{ color: 'red' }`, the rendered HTML will be:
+The variables will be applied to the component's root element as inline styles. In the above example, given a `vars` binding that evaluates to `{ color: 'red' }`, the rendered HTML will be:
 
 ```html
 <div style="--color:red" class="text">hello</div>
@@ -49,33 +49,51 @@ The variables will be applied to the component's root element as inline styles.
 
 ## Usage with `<style scoped>`
 
-When `:vars` is used with `<style scoped>`, we need to make sure the CSS variables do not leak to descendent components or accidentally shadow CSS variables higher up the DOM tree. The applied CSS variables will be prefixed with the component's scope ID:
+When `vars` is used with `<style scoped>`, we need to make sure the CSS variables do not leak to descendent components or accidentally shadow CSS variables higher up the DOM tree. The applied CSS variables will be prefixed with the component's scope ID:
 
 ```html
-<div style="--v-6b53742-color:red" class="text">hello</div>
+<div style="--6b53742-color:red" class="text">hello</div>
 ```
 
-Similarly, CSS variables inside `<style>` that matches the keys in the `:vars` expression will also be rewritten accordingly. This is also why we require the `:vars` expression to be an object literal with no computed keys.
+Similarly, CSS variables inside `<style>` will also need be rewritten accordingly. With the following code:
 
-# Alternatives
+```html
+<style scoped vars="{ color }">
+h1 {
+  color: var(--color);
+}
+</style>
+```
+
+The inner CSS will be compiled into:
 
-## Auto Detect Variables
+```css
+h1 {
+  color: var(--6b53742-color);
+}
+```
 
-One of the considered alternatives is auto detecting variables to inject using a naming convention:
+**Note that when `scoped` and `vars` are both present, all CSS variables are considered to be local.** In order to reference a global CSS variable here, use the `global:` prefix:
 
 ```html
-<style>
-.text {
-  color: var(--v-color);
+<style scoped vars="{ color }">
+h1 {
+  color: var(--color);
+  font-size: var(--global:fontSize);
 }
 </style>
 ```
 
-However, this has a few disadvantages:
+The above compiles into:
 
-- Intention is less explicit;
+```css
+h1 {
+  color: var(--6b53742-color);
+  font-size: var(--fontSize);
+}
+```
 
-- Requires a full PostCSS parse first to extract matching variables before the main script can be processed. With `:vars` being declared on the `<style>` tag, the compiler can process the `<script>` part without parsing the CSS at all.
+When there is only `scoped` and no `vars`, CSS variables are untouched. This preserves backwards compatibility.
 
 # Adoption strategy
 

From 3e0e5c8eb77d5f406746c0bf787125495eef2654 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Sat, 18 Jul 2020 16:35:45 -0400
Subject: [PATCH 10/14] update TS section regarding setup argument usage

---
 active-rfcs/0000-sfc-script-setup.md | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/active-rfcs/0000-sfc-script-setup.md b/active-rfcs/0000-sfc-script-setup.md
index c6fb46e1..2d8387f2 100644
--- a/active-rfcs/0000-sfc-script-setup.md
+++ b/active-rfcs/0000-sfc-script-setup.md
@@ -145,19 +145,19 @@ Since `export default` is hoisted outside of `setup()`, it cannot reference vari
 
 ## With TypeScript
 
-`<script setup>` should just work with TypeScript in most cases. To make implicitly injected variables like `$props` and `$emit` work with proper types, simply declare them:
+`<script setup>` should just work with TypeScript in most cases. To type setup arguments like `props` and `emit`,, simply declare them:
 
 ```vue
-<script setup lang="ts">
+<script setup="props" lang="ts">
 import { computed } from 'vue'
 
 // declare props using TypeScript syntax
 // this will be auto compiled into runtime equivalent!
-declare const $props: {
+declare const props: {
   msg: string
 }
 
-export const computedMsg = computed(() => $props.msg + '!!!')
+export const computedMsg = computed(() => props.msg + '!!!')
 </script>
 ```
 
@@ -167,19 +167,19 @@ The above will compile to:
 <script lang="ts">
 import { computed, defineComponent } from 'vue'
 
-type __$props__ = { msg: string }
-
 export default defineComponent({
   props: ({
     msg: String
   } as unknown) as undefined,
-  setup($props: __$props__) {
-    const computedMsg = computed(() => $props.msg + '!!!')
+  setup(props: {
+    msg: string
+  }) {
+    const computedMsg = computed(() => props.msg + '!!!')
 
     return {
       computedMsg,
     }
-  },
+  }
 })
 </script>
 ```

From 45365a9560ef1a1147ee53eccbc8cbb9771f2cbc Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Tue, 25 Aug 2020 17:48:28 -0400
Subject: [PATCH 11/14] edit(sfc): add details on exposing components,
 transform API and binding optimization

---
 active-rfcs/0000-sfc-script-setup.md | 90 ++++++++++++++++++++++++++++
 1 file changed, 90 insertions(+)

diff --git a/active-rfcs/0000-sfc-script-setup.md b/active-rfcs/0000-sfc-script-setup.md
index 2d8387f2..33b6e04c 100644
--- a/active-rfcs/0000-sfc-script-setup.md
+++ b/active-rfcs/0000-sfc-script-setup.md
@@ -98,6 +98,24 @@ export default {
 }
 ```
 
+## Exposing Components
+
+Exports from `<script setup>` are also available to the template when rendering components. For example:
+
+```vue
+<script setup>
+export { default as Foo } from './Foo.vue'
+export { default as Bar } from './Bar.vue'
+export const ok = Math.random()
+</script>
+
+<template>
+  <Foo/>
+  <Bar/>
+  <component :is="ok ? Foo : Bar"/>
+</template>
+```
+
 ## Declaring props or additional options
 
 One problem with `<script setup>` is that it removes the ability to declare other component options, for example `props`. We can solve this by treating the default export as additional options (this also aligns with normal `<script>`):
@@ -194,6 +212,7 @@ export default defineComponent({
 
 - The emitted code is still TypeScript with valid typing, which can be further processed by other tools.
 
+Note that the `props` type declaration value cannot be an imported type, because the SFC compiler does not process external files to extract the prop names.
 
 ## Usage alongside normal `<script>`
 
@@ -239,6 +258,77 @@ export function setup() {
 export default { setup }
 ```
 
+## Transform API
+
+The `@vue/compiler-sfc` package exposes the `compileScript` method for processing `<script setup>`:
+
+```js
+import { parse, compileScript } from '@vue/compiler-sfc'
+
+const descriptor = parse(`...`)
+
+if (descriptor.scriptSetup) {
+  const result = compileScript(descriptor) // returns SFCScriptBlock
+  console.log(result.code)
+  console.log(result.bindings) // see next section
+}
+```
+
+The compilation requires the entire descriptor to be provided, and the resulting code will include sources from both `<script setup>` and normal `<script>` (if present). It is the higher level tools' (e.g. `vite` or `vue-loader`) responsibility to properly assemble the compiled output.
+
+## Template Binding Optimization
+
+The `SFCScriptBlock` returned by `compiledScript` also exposes a `bindings` object, which is the exported binding metadata gathered during the compilation. For example, given the following `<script setup>`:
+
+```vue
+<script setup="props">
+export const foo = 1
+
+export default {
+  props: ['bar']
+}
+</script>
+```
+
+The `bindings` object will be:
+
+```js
+{
+  foo: 'setup',
+  bar: 'props'
+}
+```
+
+This object can then be passed to the template compiler:
+
+```js
+import { compile } from '@vue/compiler-dom'
+
+compile(template, {
+  bindingMetadata: bindings
+})
+```
+
+With the binding metadata available, the template compiler can generate code that directly access template variables from the corresponding source, without having to go through the render context proxy:
+
+```html
+<div>{{ foo + bar }}</div>
+```
+
+```js
+// code generated without bindingMetadata
+// here _ctx is a Proxy object that dynamically dispatches property access
+function render(_ctx) {
+  return createVNode('div', null, _ctx.foo + _ctx.bar)
+}
+
+// code generated with bindingMetadata
+// bypasses the render context proxy
+function render(_ctx, _cache, $setup, $props, $data) {
+  return createVNode('div', null, $setup.foo + $props.bar)
+}
+```
+
 ## Usage Restrictions
 
 Due to the difference in module execution semantics, code inside `<script setup>` relies on the context of an SFC. When moved into external `.js` or `.ts` files, it may lead to confusions for both developers and tools. Therefore, **`<script setup>`** cannot be used with the `src` attribute.

From 6adbdbde0b4e12970001df4eb29f3a1dcab65800 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Tue, 25 Aug 2020 17:48:40 -0400
Subject: [PATCH 12/14] remove component sugar rfc

---
 active-rfcs/0000-sfc-component-sugar.md | 132 ------------------------
 1 file changed, 132 deletions(-)
 delete mode 100644 active-rfcs/0000-sfc-component-sugar.md

diff --git a/active-rfcs/0000-sfc-component-sugar.md b/active-rfcs/0000-sfc-component-sugar.md
deleted file mode 100644
index 2fe0b737..00000000
--- a/active-rfcs/0000-sfc-component-sugar.md
+++ /dev/null
@@ -1,132 +0,0 @@
-- Start Date: 2020-06-29
-- Target Major Version: 2.x & 3.x
-- Reference Issues: N/A
-- Implementation PR: N/A
-
-# Summary
-
-Syntax sugar for reducing component import and registration boilerplate in Single File Components.
-
-# Basic example
-
-```html
-<component src="./Foo.vue"/>
-<component async src="./Bar.vue"/>
-<component src="./Baz.vue" as="Qux" />
-
-<template>
-  <Foo/>
-  <Bar/>
-  <Qux/>
-</template>
-```
-
-# Motivation
-
-Currently in SFCs you have to import a component and then pass it to the `export default { components: { ... } }` hash, which leads to a lot of redundancy: for a single component we are repeating its name 3 times: in the imported binding, the file name, and the components option.
-
-The `<component/>` sugar requires the name of each component to be specified only once.
-
-# Detailed design
-
-## Normal Components
-
-**Before**
-
-```html
-<template>
-  <Foo/>
-</template>
-
-<script>
-import Foo from './Foo.vue'
-
-export default {
-  components: {
-    Foo
-  }
-}
-</script>
-```
-
-**After**
-
-```html
-<component src="./Foo.vue"/>
-
-<template>
-  <Foo/>
-</template>
-```
-
-## Async Components
-
-**Before**
-
-```html
-<template>
-  <Foo/>
-</template>
-
-<script>
-import { defineAsyncComponent } from 'vue'
-
-export default {
-  components: {
-    Foo: defineAsyncComponent(() => import('./Foo.vue'))
-  }
-}
-</script>
-```
-
-**After**
-
-```html
-<component async src="./Foo.vue" />
-
-<template>
-  <Foo/>
-</template>
-```
-
-## Component Renaming
-
-By default, the component's locally registered name is inferred from its filename. But they can be renamed locally:
-
-```html
-<component src="./Foo.vue" as="Bar" />
-
-<template>
-  <Bar/>
-</template>
-```
-
-# Drawbacks
-
-This would require updates in tools that parse SFC content for template analysis - e.g. Vetur & `@vuedx`.
-
-However, since this information is going to be provided directly by `@vue/compiler-sfc` in the parsed SFC descriptor, it should remove some extra complexity from these tools as well.
-
-# Alternatives
-
-We considered implicitly registering imported components:
-
-```html
-<template>
-  <Foo/>
-</template>
-
-<script>
-import Foo from './Foo.vue'
-</script>
-```
-
-However, this approach has a few issues:
-
-- `Foo` is unused in the script scope, making it annoying when using linter rules that check for unused variables.
-
-- The only safe assumption about an import being a Vue component is the `.vue` extension, which makes it unable to support components authored in non-SFC formats (e.g. `import Foo from './Foo.ts'` can be a component but we can't really be sure).
-
-# Adoption strategy
-
-This is a fully backwards compatible new feature. However, we probably want to warn users against mixing the manual imports and `<component>` tags so that tools that rely on the extracted information can make safer assumptions.

From c0de1700442af8e917893a798000685e32738274 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Thu, 27 Aug 2020 09:14:49 -0400
Subject: [PATCH 13/14] update transform API example

---
 active-rfcs/0000-sfc-script-setup.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/active-rfcs/0000-sfc-script-setup.md b/active-rfcs/0000-sfc-script-setup.md
index 33b6e04c..f0ad3070 100644
--- a/active-rfcs/0000-sfc-script-setup.md
+++ b/active-rfcs/0000-sfc-script-setup.md
@@ -267,7 +267,7 @@ import { parse, compileScript } from '@vue/compiler-sfc'
 
 const descriptor = parse(`...`)
 
-if (descriptor.scriptSetup) {
+if (descriptor.script || descriptor.scriptSetup) {
   const result = compileScript(descriptor) // returns SFCScriptBlock
   console.log(result.code)
   console.log(result.bindings) // see next section

From e19fcb924bcdf42a6b930cdacd5d3b72100c946c Mon Sep 17 00:00:00 2001
From: Weiqi Wu <295290708@qq.com>
Date: Wed, 2 Sep 2020 15:26:28 +0800
Subject: [PATCH 14/14] typo (#207)

---
 active-rfcs/0000-sfc-script-setup.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/active-rfcs/0000-sfc-script-setup.md b/active-rfcs/0000-sfc-script-setup.md
index f0ad3070..e42e85bb 100644
--- a/active-rfcs/0000-sfc-script-setup.md
+++ b/active-rfcs/0000-sfc-script-setup.md
@@ -163,7 +163,7 @@ Since `export default` is hoisted outside of `setup()`, it cannot reference vari
 
 ## With TypeScript
 
-`<script setup>` should just work with TypeScript in most cases. To type setup arguments like `props` and `emit`,, simply declare them:
+`<script setup>` should just work with TypeScript in most cases. To type setup arguments like `props` and `emit`, simply declare them:
 
 ```vue
 <script setup="props" lang="ts">