status-of-vue-cli-june-2019.md

v4

Planned Breaking Changes

• ESLint has released v6, should upgrade, contribution welcome
• vue upgrade, almost done, needs tests, assigned to myself, expected to get it done before Thursday. After that we should start writing migration documentation.
• Make vuex & vue-router standalone plugins vuejs/vue-cli#4196

Needs to Fix

• PWA plugin UI (follow up of vuejs/vue-cli#2981)
• Possible Jest regression vuejs/vue-cli#4051 (comment)

Planned Non-Breaking Changes

• Plugin Ordering

  After thinking about this, I realized it's not that urgent than I previously thought. There're all kinds of workarounds for the use cases (either by hacking the API or by changing the plugin UX flow). I prefer not to touch the code base at the moment in favor of stability. We don't have that much time and energy to fix all the possible bugs coming with this big feature.

  We can add this later in a feature release if we come to a consensus on the design and implementation.

• Warn before Generator is invoked and might override uncommited changes This is needed for vue upgrade as we'll try to automatically migrate users' code

Other TODOs

See:

• intent to implement
• contribution welcome
• help wanted
• all the other bugs

Some issues have the "good first issue" label added but I didn't check them all so maybe there are more easy ones. There're also other "nice to have" features with the "enhancement" label, I haven't looked into them thoroughly so if you are willing to pick one up, please comment at it first.

maybe we can choose a more intuitive name for it, such as afterGeneration

How about afterAnyInvoke? We can move createComplete to afterInvoke. And leave postProcessFiles as it is.

module.exports.hooks

We don't need a separate object. api.afterAnyInvoke inside the generator should be enough. The reason I made a separate file is because if you see this, any plugin invocation will load all the other installed plugins to see if they have a hook. For performance reasons, instead of loading the whole generator module of the plugin, if they have a separate file called hooks.js, then it's easier to load only that one file. I am okay either way they are loaded.

delegate API

Yeah with afterAnyInvoke existing, I don't think delegate is urgent for now. We can talk about it as a separate issue.

afterAnyInvoke and afterInvoke looks good to me if they are both used inside the generator. But if that's the case, does it mean we have to actually run the generator to check hooks? Won't that be too much?

But if that's the case, does it mean we have to actually run the generator to check hooks? Won't that be too much?

That was the reason for a separate hook.js file.

Then I personally prefer the additional export object solution. Reasons:

1. Implementation details aside, generator hooks are conceptually part of the generator utility itself.
2. Usually, hooks share logic with the original generator, it makes more sense to keep them in one place.
3. It has a smaller chance of breaking existing code so we can introduce it in v3 too.

Thoughts?

Sounds good to me. Should I update the PR with everything we finalized here?

Yeah go ahead please

Will do as soon as the current router and vuex packages are done.