kikyous
Fix ES6 support using Babel::Transpiler
Tested on sprockets 3.7.1 with sprockets-es6 0.9.2, but should also work on sprockets 4 which also uses the babel-transpiler gem for es6 support.
2a9dbdf adds support for export default { } when defining components using <script lang="es6">.
There's a problem with <script lang="es6">:
While it works fine for detecting ES6 in sprockets, it breaks tooling like Vetur in VSCode, which only support javascript, coffee and ts for the langattribute.
How about autodetecting if Babel::Transpiler is defined and if it is always use the ES6 parser unless lang="coffee" is specified?
Sending non-ES6 code through babel is pretty much a No-OP, so it doesn't really hurt.
I think we can still use module.exports= in es6,
It is not unnecessary to support es6 export default
we just need a var to assign object to it
Your are right, module.exports still works in es6, but with the change it also works with export default which makes sense to use if you are writing es6. We only need the exports object because babel assumes it exists when using the export default syntax.
What do you think about auto-detection of es6 support?
I have already implemented it in my autodetect-es6 branch.
I think auto-detection is not a good way. how about
<script lang="javascript" es6>
module.exports = {
name: 'app',
data () {
return {
msg: 'Welcome to Your Vue.js App'
}
}
}
</script>
That could work, I'll have to try it out.
It could also be a implemented as a configuration setting.
export default is ok.
but I think wo should split lang transpiler in to different files,
ex. coffee.rb, es6.rb ...
In this way, we can define export={} only when needed
I thought about doing it, but I didn't see the point because it's only one extra object defined in the scope of the IIFE.
we can do it later.
Split transpiler in to different files so we can have more clear code, and no extra object