vue-coffee doesn’t build exports properly

[GeoffreyBooth]

Steps to reproduce:

git clone git@github.com:Akryum/meteor-vue2-example.git # 71830c0
meteor npm install
meteor update # Updates to 1.4.4.1, akyrum package versions as of 2017-04-24

Edit App.vue to move Session.setDefault("counter", 0); into beforeCreate, per meteor-vue2-example#9:

export default {
  beforeCreate() {
    Session.setDefault("counter", 0);
  },
  data() {

Start up the app.

meteor

It works. Stop the app.

Edit App.vue again, and change the script block to this:

<script lang="coffee">
import Chat from './Chat.vue'
import Test from './Test.vue'

import {Session} from 'meteor/session'

labels = ['Click me!', 'Click me again!', 'Here! Click here!', 'Again! Again!',
'Don\'t click me! No, I\'m just kidding. You can.', 'You like that?',
'Can you stratch me in the back please?', 'You are soooo nice! Click!',
'Hmmmm...', 'You know, you are wasting time clicking me.',
'No really, you can click me as much as you want.', 'Click me to level up!'];

export default {
  beforeCreate: ->
    Session.setDefault 'counter', 0
    return

  data: ->
    {
      buttonLabel: 'Click me!'
      count: 0
      user: null
    }

  meteor:
    data:
      count: ->
        Session.get 'counter'
      user: ->
        Meteor.user()

  methods:
    addOne: ->
      Session.set 'counter', @count + 1
      @buttonLabel = labels[Math.round(Math.random() * (labels.length - 1))]
      return

  components:
    Chat: Chat
    Test: Test

  metaInfo:
    title: 'Meteor + Vue'
}
</script>

Add vue-coffee and start the app again:

meteor add akryum:vue-coffee # Adds 0.0.4
meteor

Observe a flood of errors in the browser console:

If you revert back to the JavaScript version of the script block, but just change export default to exports.default =, you get the same errors in the console.

What extra processing is happening to export default for JavaScript code blocks, that isn’t happening to CommonJS exports.default = code blocks as produced by vue-coffee?

[GeoffreyBooth]

Workaround: You can manually do what vue-router2 does, and replace export default with return in your CoffeeScript code, and it will work.

[mitar]

So we could just be returning an object from CofeeScript's <script> and it would work? Then this is a feature. :-)

[GeoffreyBooth]

Really vue-router2 is engaging in an awful hack, just finding and replacing the string export default with return. Instead it should properly parse the file and import what is exported.

[mitar]

Why it is doing that rewrite at all? We could have export default and make it behave exactly like JS. I think maybe this was done before CoffeeScript had support for import/export?

[GeoffreyBooth]

No, it does the same thing for JavaScript code.

[mitar]

But vue-router does this only for routes.js files, not for all Vue components? So you are saying we should just start returning instead of exporting from Vue CoffeeScript components? That means we do not even have to write return, just simply have an object at the end and CoffeeScript will return it automatically?

[GeoffreyBooth]

I seems to be for all files, including components: https://github.com/meteor-vue/vue-meteor/blob/master/packages/vue-router2/plugin/plugin.js#L30

For me at least, my entire component is just one object getting exported/returned, so my script block looks like:

<script lang="coffee">
return
  name: 'someName'
  props: # ...
</script>

That was why I updated CoffeeScript in 1.12.6 to allow returning objects without braces.

Normal Vue syntax like you’d see in their docs is to use exports.default = or export default as the first line, where I have return here. exports.default is CommonJS, or what Babel converts export default into. Since the CoffeeScript is passed through Babel before vue-router sees it, if you type export default in CoffeeScript it gets converted to exports.default =, when vue-router is looking to find export default. So vue-router could be updated to search for either export default or exports.default =, and replace either one with return, and that would fix this issue.

But the brittleness of that solution just goes to show how horrible a hack it is to find-and-replace code in the first place. The regex vue-router2 is using is /export\s+default/g. So if you use the phrase export default anywhere else in your code, even in a string, it would also get replaced. This is very slipshod, irresponsible programming. This should be reimplemented to use CommonJS to properly get the module being exported, or Babel to properly parse the JS syntax rather than treat the code as one giant string.

[mitar]

Would this work?

<script lang="coffee">
name: 'someName'
props: # ...
</script>

Or I also do things like assigning it to a variable:

<script lang="coffee">
component =
  name: 'someName'
  props: # ...

component
</script>

So is return even really required?

Why wouldn't we just recommend using return in the first place instead of export default?

[mitar]

Or, why wouldn't we just change the code to simply append:

return exports.default

So if you use an explicit return, then it returns early anyway. If you do export default, it returns that.

Only implicit return as I made above would not work. :-(

[Akryum]

Meteor babel outputs reify code, so no exports.default.

[mitar]

@GeoffreyBooth, what do you think would be the best solution? Get into Meteor some support so that this conversion to return is not needed at all?

[GeoffreyBooth]

At the very least, update vue-router’s find-and-replace regex from /export\s+default/g to /export\s+default|exports.default\s=/g.

A better solution would be to use something like Esprima to actually parse the JavaScript to find any ExportDefaultDeclarations. For example, see the node tree in https://astexplorer.net/#/gist/02f13ba9babd34502296bb6fb5db86c6/0a9b81fd2f90f63edf2a6baf31756a817ccc463b:

So pass the code to Esprima to get a node tree like this, then find the ExportDefaultDeclaration (by definition there should be only one). Then the find/replace should search only within code[0..78] (in this example), and would essentially always find export default at the start of that range (index 0 here). This eliminates any potential false positives, such as “export default” appearing inside a string.

Searching for exports.default, which is what we’d need to do to handle CoffeeScript’s output, is a bit tricker. Technically exports.default = is an ExpressionStatement, and there are probably many other ExpressionStatements elsewhere in the code (e.g. foo.bar =). So you’d have to first find all the ExpressionStatements, then filter those to find the ones where the left hand side contains a MemberExpression with object exports and property default:

This tells us exactly where exports.default is: indexes 0 through 15. You then need to search from there for \s*=, to catch the equals sign too, so that you don’t output return =.

But anyway this is the “proper” way to do it, in my opinion. Treat the code as code, parsed with something that understands it.

[GeoffreyBooth]

@mitar I just reread your comment. I still stand by what I wrote above, but yes, it’s the “proper” way to do it if you’re still taking the general approach of find-and-replacing the export with return. I guess another approach would be to avoid the need for something to be returned from the Vue script block in the first place, but I’m not sure why Vue needs something returned so I can’t say.