feat(#238): isomorphic vue2 and vue3

[renatodeleao]

@ndelvalle long time no see (read) 👋

Happen to be migrating my client's codebase to vue3, had some finally some time to dedicate to OSS :)
If you're around and have time to take a look at this let me know!
Hope you're doing alright, cheers!

Implementation Details

1. Had a try using vue-demi as an attempt to make this library universal. Is more handy for the universal testing part than to the actual code, since we don't use any composition-api features yet.
2. Anyways, I've added some automated tests asserting that it works on both versions: this was the actual bulk of work. Had to install vue 2 and 3 (under an npm alias vue3) and corresponding @vue/test-utils packages.
   • test-utils.js was added with that forward exports from the correct test package for each version
   • scripts/swap-vue was copied from vuelidate, because vue-demi switch alone was not working Switching between Vue 2 and Vue 3 to run tests with Composition API vueuse/vue-demi#38
3. The migration itself was just mapping bind, update, unbind methods to their vue3 counterparts beforeMount, updated, unmounted and was done in a minute.
4. Ive also added vue requirements as peerDependencies, in conjunction with the aliased version mentioned above, makes npm install log a lot of warnings, and you'll have to pass --force flag to proceed. Once again i'm trying to copy what vue-demi actually did.

Closes #238

[ndelvalle]

Should this be "vue": "^2.0.0 || >=3.0.0"?

[renatodeleao]

In theory yes, but vue-demi only supports ^2.6.0 and since we depend on it, I opted per matching that limit.
On the 3.2.0 I don't actually remember why I did it 🤔 , maybe I had some errors while running the tests on prior v3 version, but will re-investigate.

[ndelvalle]

Hi @renatodeleao thank you for this awesome contribution ❤️, I will also add some examples to the examples folder and then release a new version 👍🏻

[renatodeleao]

@ndelvalle hold-on this for a bit longer. Installed on my real-world project (via git branch install) and some weird unrelated stuff started breaking, and i think it's related with vue-demi when paired with [email protected] + @vue/composition-api — it seems that the project starts bundling two version os @vue/composition-api

EDIT: related vueuse/vue-demi#151

[renatodeleao]

@ndelvalle update on ☝️

I don't think we'll have a "solution" soon. Depending on how consumer's vue project is bundled and which version they are using it might be necessary to apply extra configs while vueuse/vue-demi#151 and similar are sorted. So I guess we'll have to add a note to the readme, something along these lines:

### If you're using [email protected] + @vue/composition-api
If you start getting issues and suspect they came from duplicated `@vue/composition-api` calls like, the cause might be that `vue-demi` installed a second instance of `@vue/composition-api` plugin on your vue instance.

1. your `console.error` logs trace back to two different composition-api exports `.mjs` and `.common.js` as an example.
1. _the setup() binding property "x" is already declared_
1. etc

In this scenario you might need to tweak your bundler config to ensure that all your dependencies point to the same `@vue/composition-api` package:

#### Vite

// vite.config.js
// https://github.com/vueuse/vue-demi/issues/151#issuecomment-1088785153
resolve: {
  alias: [
    { find: '@vue/composition-api/dist/vue-composition-api.mjs', replacement: '@vue/composition-api' },
  ],
}
 
#### webpack

// webpack.config.js
resolve: {
  alias: {
     '@vue/composition-api$': 'path/to/node_modules/@vue/composition-api/dist/vue-composition-api.esm.js' // the one you want
  }
}

#### yarn resolutions

// package.json
// https://github.com/yarnpkg/rfcs/blob/master/implemented/0000-selective-versions-resolutions.md
{
  "resolutions": {
     "**/@vue/composition-api": "1.x" // or "file: ./path to the node_modules" version you want (depends on yarn version)
  }
}

Alternative

I guess the alternative is to drop this PR implementation relying on vue-demi and rolling a new one, probably branch based where main would be for vue2 and next would be for vue3. In my opinion, i don't think we have maintenance capacity for it.

---

Let me know what you think, when you have the time

[ndelvalle]

@ndelvalle update on ☝️

I don't think we'll have a "solution" soon. Depending on how consumer's vue project is bundled and which version they are using it might be necessary to apply extra configs while vueuse/vue-demi#151 and similar are sorted. So I guess we'll have to add a note to the readme, something along these lines:

### If you're using [email protected] + @vue/composition-api
If you start getting issues and suspect they came from duplicated `@vue/composition-api` calls like, the cause might be that `vue-demi` installed a second instance of `@vue/composition-api` plugin on your vue instance.

1. your `console.error` logs trace back to two different composition-api exports `.mjs` and `.common.js` as an example.
1. _the setup() binding property "x" is already declared_
1. etc

In this scenario you might need to tweak your bundler config to ensure that all your dependencies point to the same `@vue/composition-api` package:

#### Vite

// vite.config.js
// https://github.com/vueuse/vue-demi/issues/151#issuecomment-1088785153
resolve: {
  alias: [
    { find: '@vue/composition-api/dist/vue-composition-api.mjs', replacement: '@vue/composition-api' },
  ],
}
 
#### webpack

// webpack.config.js
resolve: {
  alias: {
     '@vue/composition-api$': 'path/to/node_modules/@vue/composition-api/dist/vue-composition-api.esm.js' // the one you want
  }
}

#### yarn resolutions

// package.json
// https://github.com/yarnpkg/rfcs/blob/master/implemented/0000-selective-versions-resolutions.md
{
  "resolutions": {
     "**/@vue/composition-api": "1.x" // or "file: ./path to the node_modules" version you want (depends on yarn version)
  }
}

Alternative

I guess the alternative is to drop this PR implementation relying on vue-demi and rolling a new one, probably branch based where main would be for vue2 and next would be for vue3. In my opinion, i don't think we have maintenance capacity for it.

Let me know what you think, when you have the time

Thanks for the research @renatodeleao. Yes, this is a tricky situation. I wonder how many people are using vue3 vs vue2.
What do you think about this approach:
Release a new version exposing a vue3 compatible API but also export the JavaScript functions to be able to also make it work with vue2.
We can add examples on how to use this new version with vue2 using the core exported functionalities of the lib, it will require a bit more work for vue2 but for vue3 will work out of the box.

[renatodeleao]

@ndelvalle I'll give one last shot trying to force dependencies as external as per latest issue comment vueuse/vue-demi#151. I will try to install this on a clean state vue2.6 + composition-api + vue-2.7 and vue3 instead projects and see what happens.

Our usecase is very simple, so yes we can also try that approach. The only downsides i'm seeing is that, by tweaking the code that way, it would be a breaking change for vue2 users and there's still a lot of people stuck with it.. so i don't know... I suspect that the majority of our users are still on vue2, but this is just a guess, because the edgy ones on vue3 maybe moved to another package in the meantime. Also, what would we do if we find a bug and need to patch the library? The vue2 users would have to go through a breaking change just to get that fix since the new version (4.x.y) no longer works for them out-of-the-box. 🤔

There's also another option that is dropping vue-demi:

1. we just use the isVue3 boolean and we can code it ourselves.
2. we don't use any @vue/composition-api feature (yet), so the benefits that vue-demi of mapping exports to the correct packages are no useful to us.

The only reason to actually use vue-demi is just to keep our our code more future proof: if we want to dive into these new composition-api features in the future, like providing a useClickOutside composable to use inside setup() as an example, we can just do it™

I'll let you know when I have news, enjoy the weekend! 👋

[renatodeleao]

@ndelvalle update: i've decided to remove vue-demi 59c518e - ⚠️ rebase alert.

The benefits we we're getting were not outweighing the cons: one extra dependency + mandatory @vue/composition-api install on consumers projects when we don't actually use any new vue3 (or backported vue2.7) composition features.

1. I've refactored with a simpl isVue3 regex test matching the version property that vue export includes.
2. I kept isomorphic testing because it's nice way to assert things are working
3. But as a check, i've tested on clean vue2 and vue3 projects and works perfectly.

If we ever get into using new vue composition functions, to avoid any mess we should just simply drop [email protected] support (or create a separate legacy branch) and support only vue2.7.x which makes sense as it this later will reach EOL by next year.

Let me know if you want me to squash commits before merge to remove this vue-demi experiment from git history.
Cheers!

[ndelvalle]

@renatodeleao thanks for the work on researching and implementing this PR. I'll create a new vue3 project on the /examples folder to have an easy to test small project.