Rule proposal: `vue/reserved-property-names`

Please describe what the rule should do:

This rule warns about using potentially reserved property names for props, data, computed properties, and methods. There’s an ongoing discussion here, but tentatively, we’re thinking of warning for any names that match the regex: /^(\$[^_]|_)/.

We’ve yet to reach consensus on the exact strategy, but we’d also like to suggest a different naming strategy for private property names used in mixins/plugins. One idea is the $_ prefix, with a suggested namespace like $_pluginOrMixinName_propertyName to avoid conflicts with other mixins/plugins.

What category of rule is this?

[ ] Enforces code style [x] Warns about a potential error [x] Suggests an alternate way of doing something [ ] Other (please specify:)

Provide code examples that this rule will warn about:

A few examples to match:

new Vue({
  data: {
     _foo: ''
  }
})

new Vue({
  data: {
     $foo: ''
  }
})

// In a .vue file
export default {
  data: function () {
    return {
      _foo: ''
    }
  }
} 

// In a .vue file
export default {
  data: function () {
    return {
      $foo: ''
    }
  }
} 

// In a .vue file
export default {
  props: ['_foo']
}

// In a .vue file
export default {
  props: ['$foo']
}

// In a .vue file
export default {
  props: {
    _foo: {}
  }
}

// In a .vue file
export default {
  props: {
    $foo: {}
  }
}

// In a .vue file
export default {
  computed: {
    _foo: function () { ... }
  }
}

// In a .vue file
export default {
  computed: {
    $foo: function () { ... }
  }
}

// In a .vue file
export default {
  methods: {
    _foo: function () { ... }
  }
}

// In a .vue file
export default {
  methods: {
    $foo: function () { ... }
  }
}

A few examples NOT to match:

// In a .vue file
export default {
  data: function () {
    return {
      $_foo: ''
    }
  }
}

// In a .vue file
export default {
  props: ['$_foo']
}

// In a .vue file
export default {
  props: {
    $_foo: {}
  }
}

// In a .vue file
export default {
  computed: {
    $_foo: function () { ... }
  }
}

// In a .vue file
export default {
  methods: {
    $_foo: function () { ... }
  }
}

[chrisvfritz]

An issue with lists is we can’t predict what might be used by Vue in the future. Using a _ or $ prefix in user code means the app could break at any time, even in a patch release, and possibly even in a dangerously subtle way that doesn’t throw an error. It would also be easy for the list to fall out of date.

[chrisvfritz]

@mysticatea No, I haven’t added it to the API reference, but may well do in the future. We just need to finalize what our official suggestion is. I’m leaning towards:

• Never to use _ or $ prefixes for private properties - use $_ instead.
• Plugins or mixins can use $ prefixes for their public API, using Object.defineProperty:

  Object.defineProperty(Vue.prototype, '$myPublicInstanceProperty', {
    get () { return this.$_pluginOrMixinName_somePrivateProperty }
  })
  

Perhaps the blacklist is sufficient for $ then, but I think we should still flag all uses of _ prefixes. The thing that really scares me is that a new conflict may arise with a _-prefixed property at any time, even in a patch release, and the resulting bug may even be subtle - or if it produces an error, that error is likely not to be very helpful to users.