Always allow Babel to transform expressions in templates

[Justineo]

Version

2.4.2

Reproduction link

https://github.com/Justineo/vue-esnext-in-template

Steps to reproduce

vue init webpack esnext-in-template

src/components/Hello.vue:

<template>
<div :class="{ a: true, ...b }"></div>
</template>

<script>
export default {
  data () {
    return { b: true }
  }
}
</script>

(babel-preset-stage-2 is already enabled after initializing with vue-cli.)

What is expected?

The class value should be a b.

What is actually happening?

Error compiling template:

- invalid expression: :class="{ a: true, ...b }"

---

vue-template-compiler seems to be validating the expression before it goes through Babel with trying to evaluate new Function(exp). This makes ES features that can be used in templates limited to those Node supports and causes confusion: I can translate spread operators for arrays both in templates and elsewhere but I can translate spread operators for objects anywhere except in templates. I think this might not be intentional so I mark this as a bug.

[nickmessing]

As a workaround for now you can use latest Node with --harmony flag to build it.

[Justineo]

@nickmessing

Thanks for the work around. But there are still some problem for this solution:

1. It's not possible to always include the workaround so it made the affected projects less portable.
2. Future ES features will always land as Babel plugins before in Node, even with --harmony flag.

[nickmessing]

@Justineo, I personally would not like to change this mechanism because if we move that away from babel-template-compiler it would result in runtime errors which make it hard to track down mistakes in templates. Another way is to try and parse it with babel instead of new Function() but that is slow and I need to research actual performance impact.

[nickmessing]

@Justineo, unfortunately, using babylon to parse expression breaks our current solution since it parses keywords successfully (ex: (do + 1)) and adds extra dependency. Looks like it's not an option and we are limited to use only code that is supported by node in expressions. --harmony solves the spread problem at the moment.

[Justineo]

Thanks Nick. I think it's better to point this out in the docs to prevent confusion. I'll make a PR later if you don't mind.

[xiuxingdeshandaiwang]

i have learned a lot

[nickmessing]

Closing this issue, doesn't seem that we can consider this further.

[chrisvfritz]

@nickmessing Any reason we couldn't just use babel-node instead of node for the build step in the Webpack template?

[posva]

@chrisvfritz I wouldn't recommend using babel-node, it has some performance overhead

[chrisvfritz]

@posva How much slower are we talking about though? I think predictable behavior is worth slightly slower builds - or even moderately slower builds. Isn't that already a trade-off we're choosing when we write tests? Or when we include a build system that compiles to more predictably supported JavaScript? 😉

[chrisvfritz]

My concern is that adding a note to the documentation won't be sufficient. When people encounter this problem, it will be nearly impossible to find that note and they could easily waste a day trying to figure out why this feature isn't working correctly - or probably more likely, just give up, assuming the Vue template compiler is buggy or lied about supporting Babel features.

If it really isn't feasible to find a consistent workaround, I think we'll need some other way to communicate to users, like catch errors in the Vue template compiler to provide a warning about this behavior.