--fix fails on custom options in order-in-components

[bbugh]

Tell us about your environment

• ESLint Version: v4.19.1
• eslint-plugin-vue Version: v4.5.0
• Node Version: v8.9.1

Please show your full configuration:

module.exports = {
  "parserOptions": {
    "parser": "babel-eslint",
    "ecmaVersion": 6,
    "sourceType": "module"
  },
  'env': {
    "browser": true,
    "es6": true,
    "jest": true,
    "jquery": true,
    "node": true,
  },
  'extends': [
    'eslint:recommended',
    'plugin:vue/recommended',
  ],
  'rules': {
    "vue/order-in-components": ["error", {
      "order": [
        "el",
        "name",
        "parent",
        "functional",
        "inheritAttrs",
        ["delimiters", "comments"],
        ["components", "directives", "filters"],
        "extends",
        "mixins",
        "model",
        ["props", "propsData"],
        "data",
        "validations",  // new order-in-components
        "computed",
        "watch",
        "LIFECYCLE_HOOKS",
        "methods",
        ["template", "render"],
        "apollo",  // new order-in-components
        "renderError"
      ]
    }]
  }
}

What did you do? Please include the actual source code causing the issue.

When using the custom configuration, I would expect the following listing to be automatically organized, but it's not. All of the properties are organized, but my custom properties are ignored by --fix.

{
  validations: { ... },
  apollo: { ... }
  mixins: [],
  methods: { ... },
  data () { ... },
  props: { ... },
}

What did you expect to happen?

The file should be automatically organized into this listing:

{
  mixins: [],
  props: { ... },
  data () { ... },
  validations: { ... },
  methods: { ... },
  apollo: { ... }
}

What actually happened? Please include the actual, raw output from ESLint.

When running without --fix, it appears like this:

  43:3  error  The "mixins" property should be above the "validations" property on line 32  vue/order-in-components
  44:3  error  The "methods" property should be above the "apollo" property on line 42      vue/order-in-components
  45:3  error  The "data" property should be above the "validations" property on line 32    vue/order-in-components
  57:3  error  The "props" property should be above the "data" property on line 45          vue/order-in-components
  63:3  error  The "watch" property should be above the "methods" property on line 44       vue/order-in-components
  68:3  error  The "mounted" property should be above the "methods" property on line 44     vue/order-in-components

When running with --fix, it does not fix the properties.

  52:3  error  The "mixins" property should be above the "validations" property on line 32  vue/order-in-components
  53:3  error  The "props" property should be above the "validations" property on line 32   vue/order-in-components
  59:3  error  The "data" property should be above the "validations" property on line 32    vue/order-in-components

The file ends up looking like this, which is not the expected order at all:

{
  validations: { ... },
  methods: { ... },
  apollo: { ... }
  mixins: [],
  props: { ... },
  data () { ... },
}

This issue seems to be related to this pull request: #381

[bbugh]

More discovery: this seems to be related somehow to the property's nested sub properties.

If validations has a specific configuration of nested sub properties, validations won't be automatically moved to the expected location in the component properties. Here's some test cases:

// This will be sorted correctly in the component properties:
validations: {},

// This will be sorted correctly in the component properties:
validations: {
  form: {
    field1: { required },
    field2: { required, required, required },
  }
},

// This WILL NOT be sorted correctly in the component properties
validations: {
  form: {
    field1: { required },
    field2: { required, between: between(0, 99) }, // this is the failure point
  }
}

[michalsnik]

I just confirmed it @bbugh I see this problem on my computer too. Will try to fix it soon

[michalsnik]

Oh, sorry @bbugh I just realised - this is an intended behaviour. See #381 (comment)

If you won't have side effects in properties they'll properly reorder, but if we're not 100% sure - we stop fixing the code, so that you can do it more carefully.

[bbugh]

@michalsnik thanks for the information, I saw that in the pull request. I don't understand how that matters for this. It's reordering the top level elements in the main object for readability, which doesn't care about how things are ordered.

Is there some way to disable this extra strict mode or reduce the strictness?