xstate: @xstate/vue not working with vue beta

Yeah, so we’d go with vue@3.0.0-rc.1 (or above) as the peer dependency to retrieve Vue’s composition functions. Since the package is still in v0, I guess it’s okay to simply go up a minor (as defined by semver).

For Vue 2, the recommendation from the recipe is to use the Options API. Vue 2 users who are already using @xstate/vue’s composition functions with @vue/composition-api will have to either stick to the current version of the package, move back to the Options API, or upgrade to Vue 3 (which we’ll need to document here and here). If they didn’t pin their dependencies, things may break for them, but according to semver rules, that’s their responsibility. Are we good on this?

If yes, I’ll PR soon 🙂

Are we good on this?

Yes! ✅

There are two ways to use the Composition API:

• Using the @vue/composition-api Vue 2 plugin
• Built-in in Vue 3 beta

The problem comes from the fact that this file tries to import Composition functions from @vue/composition-api. This is why @xstate/vue needs it as a peer dependency; yet in Vue 3 beta this isn’t compatible.

If you want @xstate/vue to be available in Vue 2 with the @vue/composition-api plugin, you’ll likely want to expose two entry points and set @vue/composition-api as an optionalDependency. If you don’t, and only care about the Composition API in Vue 3, you can switch the peer dependency to Vue and change the import source. That would require a major release though.

Let us know what your vision is for this @davidkpiano. I’d be happy to PR.

@davidkpiano My thought is that the Composition API is ultimately meant to be used in Vue 3.

The Vue 2 plugin was a great way to discover the API and get familiar with it while Vue 3 was being developed, but there’s a high chance that it ends up being deprecated and users are encouraged to upgrade. The plugin has limitations and a performance impact in Vue 2 because the Vue 2 API wasn’t designed for it.

Of course, this is only my guess as an individual Vue developer. I’m not a Vue team member, nor do I speak for the entire community. I asked on the repo what the future of the plugin is to get more objective data. Additionally, as soon as Vue 3 comes out (which should be anytime now since it’s in RC as we speak), Vue 2 will go in LTS for no longer than 18 months (and then another 18 months in maintenance mode). Finally, you can see a significant drop in npm downloads for @vue/composition-api over the last few weeks.

I would personally recommend going with the second option as well. It’s going to be much easier to maintain, and users willing to try the XState Composition functions within Vue 2 with the @vue/composition-api plugin can still install the current major version (which we can document).

UPDATE: As suggested by this reply, the plugin isn’t likely to get deprecated. It will go to v1 and hopefully, the last minor release of Vue 2 will backport enough features to remove performance issues and limitations. Yet, there’s a plugin that allows library maintainers to write Vue 2/3 universal APIs, that could be an interesting solution. Based on the detected local version of Vue, it either installs the @vue/composition-api plugin or not with a postinstall script, and routes the imports to the right package (vue or @vue/composition-api). The plugin is non-official and experimental though, so it could bring additional bugs. It may be a big risk for such a critical dependency. The way I see it, that solution could be considered if @xstate/vue users massively start asking for it once the new major is out.

@sarahdayan Thanks so much for this. My assumption is that Vue developers who want to use the composition API are probably already using Vue 3 beta, so Vue 2 developers can use the implementation in the docs. Does this seem accurate?

If that’s right (and we want to avoid supporting multiple entry points), I would vote to do the second option (switch peer dep to Vue, major release).

What do you think?

@sarahdayan sorry - I’ve subconsciously mapped yarn test in the contributing guide to yarn dev which I’m using when developing. I’ll adjust the guide later to explain both options - for me yarn dev works great because it’s a combined yarn build & yarn test (with just some extra lines on top of that), with just yarn test u might end up with your tests running against outdated dist files because sources are not automatically rebuilt to dist files on code changes.

Thank you! Working on the fix as we speak. Expect a PR soon.

@nour-dev @dennzimm -

I’ve published a stopgap package use-xstate, that has the same API as documented but will work with Vue 3.

This package should only be used for interim development while official support is added - but the APIs should match so switching packages once official support is added should be trivial.

As a side note: it’s generally considered poor form to ping open-source projects asking for status updates. Please think of the fact that maintainers are generally volunteering their free time to make these things, and don’t need additional pressure from people asking when something will be done.

Should you like faster progress, it’s best to start finding out how you can help!