Global API Change about core HOT 11 CLOSED

This is similar to using the provide option in a 2.x root instance.

Will we do a separate RFC for provide/inject as a whole or are we planning to keep the provide API in components intact?

from core.

Concerning Adoption strategies: The compatibility build won't be able to provide complete compatibility in this regard, since an "old" app would still try and use the global constructor to do mixins etc., right?

from core.

Will it break the auto-installation feature like vuex or vue-i18n?

<script src="/path/to/vue.js"></script>
<script src="/path/to/vuex.js"></script>

If I don't misunderstand we couldn't "install" or "use" a feature before an app created. Does it mean this kind of global installation would be banned?

Thanks.

from core.

And currently Vue.extend({}) seems able to solve the same problem as an app instance does. As I remember it works well in an earlier version of Weex. So I think the current design is also fine if we want to keep auto-installation supported.

from core.

@Jinjiang yes, this is a breaking change and it will break auto installation. If we still allow implicit global installation it would make this change pointless.

from core.

Hm.

Would the Plugin API (install function receiving the/a Vue constructor) be the same though?

I don't want to break every plugin in the whole ecosystem :(

from core.

@LinusBorg most plugins should be able to remain unchanged, with some exceptions:

• implicit global installations won't work anymore

• if a plugin relies on tree-shakable global APIs (e.g. nextTick), these won't be available on the passed app instance anymore and must be separately imported (e.g. import { nextTick } from 'vue').

from core.

Couldn't we try and find some middle ground for 3.0 and just deprecate it and then drop this in 4.0?

Maybe something like this:

1. Vue.use() adds plugins it recieves to some cache
2. A deprecation warning is logged during development.
3. When running createApp(), these plugins are applied to the app instance in the background.

This would ensure backwards compatibility while giving people the possibility of using the new api in their apps if they want to keep the plugins local to their app instance.

from core.

but what is the deal with global plugin install? it only worked while prototyping

from core.

it only worked while prototyping

Not sure what you mean.

I'm sure there are a ton of production apps out there that use Vue in server-rendered pages and include it from a CDN, along with plugins:

<script src="http://unpkg.com/vue/dist/vue.min.js"></script>
<script src="http://unpkg.com/some-plugin.min.js"></script>

some-plugin would try and call Vue.use(SomePlugin), which won't work anymore in Vue 3.

Sure, people have to upgrade their dependency and some code anyways, but the point is that this requires the plugin author to upgrade their plugin's code to work with Vue 2 and 3 differenty, and add documentation about this etc.

In short: It's another thing plugin authors have to do to ensure Vue 3 compatiblity, and it's not done by just compiling a new bundle with the new template compiler and correcting a few little things in the code, now they need to update docs as well etc.

I think this is one of those things that we should deprecate and not just take away from people, as I generally have a bad feeling about potentially underestimating the amount of churn pain we will be inflicting on people with all of the things we are changing.

from core.

Published: https://github.com/vuejs/rfcs/blob/global-api-change/active-rfcs/0000-global-api-change.md

@LinusBorg I think a middle ground (as included in the public RFC) is to provide stubs that emit warnings for these moved methods. For example if a plugin calls Vue.use(), it will be a noop and emit a warning that tells the user to explicit call app.use() for related plugins. This way plugin authors won't have to do anything regarding migration.

from core.