Enable loading locally installed Vue compiler

[akanix42]

Currently, the user is forced to use the version of Vue that matches the vue-template-compiler package that is bundled with this plugin. If the user has a newer version of Vue, the build crashes with the following error:

   Vue packages version mismatch:
   
   - vue@2.5.16
   - vue-template-compiler@2.5.13
   
   This may cause things to work incorrectly. Make sure to use the same
   version for both.
   If you are using vue-loader@>=10.0, simply update
   vue-template-compiler.
   If you are using vue-loader@<10.0 or vueify, re-installing
   vue-loader/vueify should bump vue-template-compiler to the latest.

Rather than force the user to downgrade their vue version, this PR enables the user to npm install the latest version of the vue-template-compiler and vue-template-es2015-compiler and have the plugin automatically use them if available.

[mitar]

Are you sure this is required? For me it works without this pull request to have a custom Vue installation with then fixed vue-template-compiler by just installing it at top-level of the app (Vue is installed the same).

[mitar]

Hm, after more thought I think that this is related to #312 and meteor/meteor#9865. I think in past version of Meteor you could access peer dependencies from a plugin. Because of that if you installed custom Vue and custom vue-template-compiler in your app, same version, it just worked out. But maybe now you cannot anymore? So it find the vue-template-compiler bundled with the plugin?

But I do have on 1.6.1.1 exactly this setup. Custom Vue (fork) and matching vue-template-compiler version, installed in app's node_modules and it still works. So I am not sure what is happening here.

[akanix42]

I did some testing and the Vue packages version mismatch: if you have the vue-component package installed locally. If you are using the package from Atmosphere, the error message will be suppressed because the code that checks for the mismatch is unable to load the locally installed version of vue. In other words, you should still be getting the error but aren't. It doesn't mean that your app won't work - I assume you'll only encounter issues if you use template features from a newer version of vue than the bundled vue-template-compiler plugin, or if there are breaking changes between the version of vue you have installed the version of the vue-template-compiler that is bundled with the vue-component package.

I verified that the local vue-template-compiler is not being loaded by modifying the code in the local version found at node_modules/vue-template-compiler/index.js and in the bundled version found at %USERPROFILE%\appdata\local\.meteor\packages\akryum_vue-component\0.13.1\plugin.vue-component.os\npm\node_modules\meteor\vue-component\node_modules\vue-template-compiler on Windows.
To both of these files, I add the following on line 7:

console.log('package version', packageVersion)

I have v2.5.16 installed locally, but when I start my application, the console outputs:

package version 2.5.13

In doing more testing with the changes in this PR, I've discovered another issue: when building for the client, Meteor uses the browser field in the vue-template-compiler's package.json instead of the main entry, which prevents the version check from running at all. I've opened an issue for this. So in this case, if you have a mismatch between your locally installed versions of both vue and the vue-template-compiler, you will still not receive the error message so long as your files are inside of a client folder. If your files are also built on the server, the message will be displayed.

[Akryum]

Thanks! 👍

[mitar]

If you are using the package from Atmosphere, the error message will be suppressed because the code that checks for the mismatch is unable to load the locally installed version of vue.

That is not true. For all my apps I have to use Vue fork because otherwise all of my reactivity integration would not work. But it works. So vue-component does manage to load my Vue fork in app's node_modules. See this example. Based on my experience with other PR it should not work, I agree, but it does. I have no idea why. :-) I think this PR is great and is solving the problem in the right way, I just do not get it why these differences.