great! 🚀

docs would need some additional love, too:

https://next.vue-test-utils.vuejs.org/guide/advanced/third-party.html
https://next.vue-test-utils.vuejs.org/guide/advanced/reusability-composition.html
https://next.vue-test-utils.vuejs.org/guide/advanced/transitions.html

My suggestion list:

• reinstantiate enableAutoDestroy / resetAutoDestroy API - while relatively fresh - it is used in some projects and I see it as a good idea for making sure our tests are safe and we do not loose this when migrating to 2.0
• port feat: warn when operating on destroyed Vue component, fix #1685 vue-test-utils#1706 to this repository - it proven as a great tool from shooting ourselves in a leg, and is quite trivial to port
• port feat: remove deprecation when is is called with component definition vue-test-utils#1676 to 2.0 (see rationate in PR) - I still see .is being useful to build assertions against specific components (required when you're using with shallowMount and component :is="something" to check that proper component is rendered)
• I'm going to take a closer look at docs: How to handle code snippets? #301 - it really feels like good and important addition - as @marina-mosti pointed in Request to reinstate ability to use CSS selectors in findComponent #904 (comment) our code snippets might be easily run out of date and having them in sync with real codebase might be in great help

great! rocket

docs would need some additional love, too:

Definitely, first comment updated ❤️ 📝

@afontcu @lmiller1990 @cexbrayat Your input will be invaluable here
Let me know also about my suggestion list and for each accepted proposal I will open relevant issue here

I think I have a fix for #806 somewhere, I can get it done this weekend.

• vue-test-utils#1706 Seems trivial, let's do it
• enableAutoDestroy Yes, I think this is also easy to port
• Request to reinstate ability to use CSS selectors in findComponent #904 Yes, I believe @xanf is doing this
• support is - don't really have a strong opinion here

I think we should tag all relevant issues with a 2.0.0 tag or something, so we do not need to track it manually.

How about we set a goal to make sure this happens - I'm going to suggest October 31st?

At the moment I'm seeing this issue: vuejs/vue-test-utils#1833 also in 2.0.0 rc 16.

@boboldehampsink The issue you're mentioning is for VTU v1 (for Vue v2), whereas this repository is for VTU v2 (for Vue 3)

If you're encountering it with Vue 3 and VTU v2, please open a dedicated issue with a reproduction so we can take a look.

@cexbrayat yes encountering this with Vue 3 and VTU v2. The issue is exactly the same tho. Probably worth fixing in v1 and then you'll be able to fix it for v2 too.

@boboldehampsink The issue you're mentioning is for VTU v1 (for Vue v2), whereas this repository is for VTU v2 (for Vue 3)

If you're encountering it with Vue 3 and VTU v2, please open a dedicated issue with a reproduction so we can take a look.

New issue filed here: #1076

Seems, outside of Vue Jest specific problems w.r.t stubs, we are good to hit 2.0.0?

Once all fails here pass: #1293 we will do 2.0.

Is it good practice to release a version when the dependencies are yet not published properly. I have seen this with v5 of vue cli jest as well. v2 will hold v27-rc of vue-jest, shouldn't you guys collaborate and ask dependent libraries to publish first. This is not an issue with individual devs but there are scans in place in enterprises, and in my company, we are kind of confused to go with vue 3 now

It's just a version number - transitioning from RC to 2.0.0 is more or less an arbitrary decision, since there's no official spec to build by. The RC - release candidate - just means "it's pretty much ready for prime time, bar a few known issues".

That said, if your company is concerned, the only thing blocking 2.0.0 is two failing tests: #1293.

If you (or someone else who's concerned about the RC status) would like to fix those, we can move to 2.0.0 🎉

I think this can be closed, as we finally have 2.0.0 🚀