Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Supports for Vue.js 3.x #1035

Closed
71 of 75 tasks
ota-meshi opened this issue Jan 15, 2020 · 30 comments
Closed
71 of 75 tasks

Supports for Vue.js 3.x #1035

ota-meshi opened this issue Jan 15, 2020 · 30 comments

Comments

@ota-meshi
Copy link
Member

ota-meshi commented Jan 15, 2020

In this issue, I will list the Vue.js 3.x changes that need to be supported by eslint-plugin-vue.



List the changes after #1036 was merged.


refs

https://medium.com/the-vue-point/plans-for-the-next-iteration-of-vue-js-777ffea6fabf
https://github.com/vuejs/rfcs/pulls?utf8=%E2%9C%93&q=is%3Apr+label%3A3.x+
https://vueschool.io/articles/vuejs-tutorials/exciting-new-features-in-vue-3/
https://vue-composition-api-rfc.netlify.com/

@sodatea
Copy link
Member

sodatea commented Jan 16, 2020

/cc @vuejs/docs

I think these changes are also to be addressed in the new style guide.
Any thoughts?

@sodatea
Copy link
Member

sodatea commented Jan 16, 2020

I think a require-v-if-inside-transition rule can be added for RFC0017

@yyx990803
Copy link
Member

yyx990803 commented Jan 16, 2020

Some rules I had in mind:

  • no-ref-as-operand:

    Detect cases where a ref is used incorrectly as an operand in binary operations. + is probably the most common case for such errors. For example:

    const count = ref(0)
    
    count++ // error
    count + 1 // error
    1 + count // error

    A ref used as the condition in a ternary is probably also an error:

    const ok = ref(true)
    
    const msg = ok ? 'yes' : 'no' // error
  • no-watch-after-await & no-lifecycle-after-await:

    In setup(), watch and onXXX lifecycle hooks should be registered synchronously. So their usage should be prohibited in async setup() after await statements:

    async setup() {
      watch(() => { /* ... */ }) // ok
      onMounted(() => { /* ... */ }) // ok
    
      await doSomething()
    
      watch(() => { /* ... */ }) // error
      onMounted(() => { /* ... */ }) // error
    }
  • no-setup-props-destructure

    Destructuring the props passed to setup will cause the value to lose reactivity.

    // Do
    setup(props) {
      watch(() => {
        console.log(props.count) // ok
      })
    
      return () => {
        return h('div', props.count) // ok
      }
    }
    
    // Don't
    setup({ count }) { // error
      watch(() => {
        console.log(count) // not going to detect changes
      })
    
      return () => {
        return h('div', count) // not going to update
      }
    }

    Also, destructuring in root scope of setup() should error, but ok inside nested callbacks or returned render functions:

    setup(props) {
      const { count } = props // error
    
      watch(() => {
        const { count } = props // ok
        console.log(count)
      })
    
      return () => {
        const { count } = props // ok
        return h('div', count)
      }
    }

@ota-meshi
Copy link
Member Author

ota-meshi commented Jan 17, 2020

@sodatea @yyx990803 Thank you for your comments!

I have added new rules to the list.

@ota-meshi
Copy link
Member Author

@michalsnik @mysticatea Could you comment on this issue if you have any feedback?

@codebender828
Copy link

Hi! Thanks @ota-meshi @sodatea @yyx990803 for the work done with this plugin.

Will we be adding any rules for when consumers try to access refs in the template through .value? I feel like some people would try to do this, yet based on the RFC docs, Vue internally does this for you.

@yyx990803
Copy link
Member

@codebender828 that's a good one, although a user may very well have an object with .value so we will need the component's type information to be able to warn without false positives.

@przemkow
Copy link
Contributor

przemkow commented Jan 25, 2020

I have a question about v-model changes. 🙂
If i understood RFC 0011 right, v-model api will provide also support for custom modifiers.
Adding that feature wouldn't require also some changes to vue/valid-v-model rule?
Ex.:

  • Modify vue/valid-v-model rule to provide support for custom modifiers.
  • Add vue/no-custom-modifiers-on-v-model rule to checks if v-model does not contain custom modifiers (Vue 2 backward compatibility)

@yyx990803
Copy link
Member

Note that custom modifiers are only supported for v-model on custom components. Usage on native <input>, <select> and <textarea> still only support the built-in modifiers.

@ota-meshi
Copy link
Member Author

@przemkow Thank you for your comment. And thank you for your contribution.
I overlooked the custom modifiers change.
I think we need to change the valid-v-model rule and add new rule as you say.

@przemkow
Copy link
Contributor

przemkow commented Jan 26, 2020

Thank you for the clarification @yyx990803 🙂
No problem @ota-meshi 😉 I hope this contribution will be helpful for the whole community.

I updated previously created PR ( #1039 ) so now it handles both RFC0005 and RFC0011.

@przemkow
Copy link
Contributor

przemkow commented Feb 2, 2020

@ota-meshi setup function should be added to vue/no-dupe-keys rule as well isn't it?

@ota-meshi
Copy link
Member Author

@przemkow I think it needs to be added as you say.

@chiptus
Copy link

chiptus commented Feb 9, 2020

what about no this in setup function? I really miss that in eslint on vue2

@victorgarciaesgi
Copy link

I was thinking of adding something similar to react-hooks/exhaustive-deps that autofix in the return statement all the reactive and ref variables present in the setup function

@ota-meshi
Copy link
Member Author

Hi @chiptus @victorgarciaesgi. Sorry for the late reply.
Could you open a new issue and include sample code?
Because I don't understand your proposed rule correctly.

@victorgarciaesgi
Copy link

@ota-meshi Sure!

Consider this code in React

export function Component() {
  const isMobile = useMedia({ maxWidth: '768px' })

  useEffect(() => {
    if (isMobile) {
      console.log(isMobile)
    }
  })
  return <div>{isMobile}</div>
}

With the rule react-hooks/exhaustive-deps, eslint will autofix the code to add missing deps to useEffect, resulting in:

useEffect(() => {
    if (isMobile) {
      console.log(isMobile)
    }
  }, [isMobile])

In Vue3 we can have the same thing but for the return statement in setup
Exemple:

export default defineComponent({
 setup(props, ctx) {
  const search = ref('')
 } 
})

Will become:

export default defineComponent({
 setup(props, ctx) {
  const search = ref('')
  return {search}
 } 
})

@LinusBorg
Copy link
Member

I'm not too sure about this. I'm pretty sure we will rather often have state in setup that doesn't have to be exposed to the template.

@victorgarciaesgi
Copy link

@LinusBorg Yeah i thought of that too, maybe complete the return statement with only values present in the template?

@yoyo930021
Copy link
Member

Does we need about no-this-in-setup rule?

@sodatea
Copy link
Member

sodatea commented Apr 16, 2020

We also need a vue/no-inline-template for RFC0016: Remove inline-template

@ota-meshi
Copy link
Member Author

Hi @sodatea. I haven't used the inline-template and I'm not familiar with it.
Can the inline-template be used in SFC?

@sodatea
Copy link
Member

sodatea commented Apr 16, 2020

Yeah, it can be used in SFC.

@ota-meshi
Copy link
Member Author

ota-meshi commented Apr 16, 2020

I did not know that. Thank you!

@sodatea
Copy link
Member

sodatea commented Apr 28, 2020

Per RFC0007, I think a no-functional-template rule is needed. I'm not sure if it's auto-fixable though.


I just found out that the no-reserved-component-names rule does not throw on Vue's own built-in component names like transition, transition-group, keep-alive and component. As of Vue.js 3.x, teleport should be added to the list too.


Per RFC0027, we need a new rule to restrict the is prop usage to the reserved <component> tag only.

@sodatea
Copy link
Member

sodatea commented Apr 29, 2020

The vue/no-deprecated-v-on-number-modifiers rule needs to also detect the usage of Vue.config.keyCodes and warn the deprecation.

@ota-meshi
Copy link
Member Author

@sodatea Thank you for suggesting the rules and changes.
I will make those changes.

@sodatea
Copy link
Member

sodatea commented May 9, 2020

Thanks!

@ota-meshi
Copy link
Member Author

Currently this plugin has finished implementing most of the rules defined in this issue.

Open the remaining issue with another and close this issue.

If you would like to propose a new rule, please open a new issue.

@yyx990803
Copy link
Member

@ota-meshi thanks for the hard work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants