Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Roadmap for version 4 #3649

Closed
16 of 19 tasks
sodatea opened this issue Mar 16, 2019 · 52 comments
Closed
16 of 19 tasks

Roadmap for version 4 #3649

sodatea opened this issue Mar 16, 2019 · 52 comments

Comments

@sodatea
Copy link
Member

sodatea commented Mar 16, 2019

It's time for a major version bump.
This will be a relatively small release but will include a number of necessary breaking changes.

Planned Features

Dependency Updates

Changed Behavior

New Features

Most proposed new features other than plugin APIs can also be landed in v3.x so they are not listed here.

Removed

Needs Discussion

  • Drop unit mocha in favor of Jest only
    • Mostly because mocha-webpack is unmaintained and unlikely to work with webpack 5
    • Need good migration strategy for existing users
  • Use mochapack instead of mocha-webpack
  • Upgrade to mocha v6

How Can I Help?

Please let us know your thoughts and if we missed anything.
We'll be more than happy to explain our rationale around these decisions if there's any further questions.

If there's anything you (and the community) feel strongly about but is not found on this list, please make an effort to send a PR!
We'll be more than happy to accept contributions.

@edimitchel
Copy link

Mocha is much faster than Jest. Keep it.

@NeiPCs
Copy link

NeiPCs commented Mar 20, 2019

Yep, since we know what breaking changes will apply, we can work on documentation of migration from X to Y version.

@LinusBorg
Copy link
Member

LinusBorg commented Mar 21, 2019

Mocha is much faster than Jest. Keep it.

We would, if someone can assure us mocha-webpack will continue to work with webpack 5 even though it's currently unmaintained.

Otherwise we just keep a feature alive that is destined to die soon anyway.

@salvadordiaz
Copy link

There is a fork of mocha-webpack that works with webpack 4 and mocha 4, 5 and 6:
https://github.com/sysgears/mochapack

I really hope that we can avoid having to migrate our test suite from mocha to jest.

@Garito
Copy link

Garito commented Mar 22, 2019

My 5 cents: the simpler the better

@LinusBorg
Copy link
Member

@salvadordiaz That looks promising, assuming the author is up to upgrade it to webpack 5 compatibility when that time arrives.

@geedew
Copy link

geedew commented Mar 22, 2019

Is there a discussion ticket for the Codemods work?

@LinusBorg
Copy link
Member

LinusBorg commented Mar 22, 2019

Nope. Also, we should probably do a real RFC for his as the vue-cli repo is one of the repos we included for the official RFC process in https://github.com/vuejs/rfcs#when-to-follow-this-process

We might discuss possibly deprecating mocha there as well, as it's likely a hot topic.

@yannick-milanetto
Copy link

yannick-milanetto commented Mar 23, 2019

Is there any plans to support server-side rendering in core, without having to go for a 3rd party plugin ?

@larixer
Copy link

larixer commented Mar 23, 2019

@LinusBorg Hi, I'm the maintainer of mochapack. Is Webpack 5 support is the only thing you need to continue using mocha unit tests and mocha-webpack, or have you made a decision to drop mocha tests in favor of jest already?

@LinusBorg
Copy link
Member

@Vlasenko Hi 😁

We haven't made that decision, that's what this issue is meant to discuss.

We don't want to "get rid" of mocha. Until someone mentioned your fork, we just didn't see any future for it since mocha webpack was unmaintained.

So if you ate panning to keep on working on mochapack and make it work with webpack 5, my opinion would be to keep it 🙂

@larixer
Copy link

larixer commented Mar 23, 2019

@LinusBorg Great! Yes, I plan to keep on working on mochapack and add Wepback 5 support to it. I will notify you here, when Webpack 5 support will be ready in mochapack.

@cngu
Copy link

cngu commented Mar 25, 2019

@LinusBorg Hi! Based on the discussion here #947 (comment), has an alternative for inject-loader been investigated yet?

If not, Jest has some complimentary features to help replace inject-loader that you may want to consider when comparing it with Mocha.

@pksunkara
Copy link
Contributor

Thanks for creating this @sodatea and @LinusBorg. It's good to see the development of this repo is more transparent now. I can work on the new features (some of it already done) since I was the one who was requesting them mostly. We can discuss more if you guys want. I will be available in the Vue Discord.

@pksunkara
Copy link
Contributor

@geedew

Is there a discussion ticket for the Codemods work?

There is some discussion about the scenarios that need to be handled in #1507 when the original work for vue-upgrade has been done.

For an example issue that rose up because vue-upgrade is not properly done is in storybook plugin linked here

@KyLeoHC
Copy link

KyLeoHC commented Mar 28, 2019

Think about replacing tslint with typescript-eslint.And replace ts-loader with babel7.

@LinusBorg
Copy link
Member

replacing tslint with typescript-eslint

We will do that once typescript-eslint has the announced feature parity with tslint.

And replace ts-loader with babel7.

Since babel's typescript implementation comes with some significant limitations we probably won't do that.

@andreiTn
Copy link
Contributor

andreiTn commented Apr 3, 2019

TSLint doesn't detect HTML errors inside .
Steps to reproduce:

  1. Create a new Vue project with Typescript and TSLint.
  2. Create an error inside HTML in a .vue file. For example, remove an angle bracket < from a tag.
  3. Run yarn lint

Output: No lint errors found!

ESLin detects this, however, I don't know if I should use ESLint with Typescript or ESLint together with TSLint. Is this something that you could look into for the next version?

@IndexXuan
Copy link
Contributor

@andreiTn you should use eslint with ts,since it support ts and will support by the core ts team in the futher. tslint is deprecated!

@andreiTn
Copy link
Contributor

andreiTn commented Apr 4, 2019

Thanks @IndexXuan

@752
Copy link

752 commented Apr 11, 2019

update html-webpack-plugin to 4.x ?
jantimon/html-webpack-plugin#878
jantimon/html-webpack-plugin#1069

@LinusBorg
Copy link
Member

Sure, once it's out of beta (currently: 4.0.0-beta.5)

@alvarosabu
Copy link

alvarosabu commented Apr 12, 2019

Have you guys ever thought about adding commands for scaffolding, to easily create views, components, stores? Similar to https://github.com/hjeti/vue-generator. You can also create a directory with your own templates (with your code conventions) inside of your project.

@moranje
Copy link

moranje commented Jun 23, 2019

Hope you are aware of:

https://eslint.org/docs/6.0.0/user-guide/migrating-to-6.0.0

@ashleynolan
Copy link

Are there any plans to add ES6 module output to the library build mode in a future version of vue-cli?

@sodatea
Copy link
Member Author

sodatea commented Jul 12, 2019

@ashleynolan pending webpack/webpack#2933

@ffxsam
Copy link
Contributor

ffxsam commented Jul 13, 2019

Another vote to get rid of the TSLint option in vue-cli, as it's being deprecated. I've replaced it in one of my projects with the new TypeScript ESLint plugin, and does just fine validating my code.

Full ruleset here.

EDIT: If TSLint must remain, perhaps the inclusion of a deprecation warning would be a good idea.

@sodatea
Copy link
Member Author

sodatea commented Jul 14, 2019

@ffxsam PR submitted #4289

@bodograumann
Copy link
Contributor

I see the “vue upgrade” item is marked done. There are some open in points in #4090 though. Most importantly there is no documentation for the MigrationAPI.

Secondly, the linked tickets for “plugin ordering” are resolved by #2337. Is there anything else planned for 4.0?

Finally, any predictions on a release date?

@sodatea
Copy link
Member Author

sodatea commented Jul 24, 2019

For the vue upgrade command:
It still needs refinement, but is usable. So it won't block v4 stable release, we can do the refinement in later feature releases.

The MigratorAPI:
It's the same as GeneratorAPI with an additional fromVersion(range) method. I'm working on the documentation.

Plugin Ordering:
Not fully resolved, but the most common concerns have been addressed and I believe most use cases can be solved or worked around with the latest API.
No major new features planned as of now.

Release date:
v4 is now in beta, meaning it's mostly usable with maybe a few glitches. Feedbacks are welcome.

The next step is to fix noticeable bugs and to refine the documentation.
Actually, I'm working on a blog post to introduce its major changes but haven't got the time to finish it.
I'd like to complete the beta and then rc phase in the coming weeks, but this is not set in stone, in case any major issues encountered during the test.

@falstack
Copy link

Multiple Component Lib support.

src dir

// src
-- componentA
  |-- index.js
  |-- a.vue
-- componentB
  |-- index.js
  |-- b.vue

build script

"build": "vue-cli-service build --target lib --name myLib 'src/**/index.js'"

output dir

// dist
myLib.xxx.js
myLib.min.css
componentA
  |-- index.js
  |-- style.css
componentB
  |-- index.js
  |-- style.css

@bodograumann
Copy link
Contributor

typescript-eslint version 2.0.0 was just released!
Lots of changes; probably requires modifying @vue/eslint-config-typescript. Oh, just seeing that that has been moved to its own repository. So not sure how you want to handle this.

@pksunkara
Copy link
Contributor

eslint-config-airbnb 14.0.0 released to be in line with eslint 6

@sodatea
Copy link
Member Author

sodatea commented Aug 18, 2019

ESLint config versions are managed separately from @vue/cli-plugin-eslint.
If they have new versions, the default config versions used for generating new projects will be bumped in a minor release of the plugin.

I'd also like to implement an upgrade hook in the plugin, to prompt the user to optionally update the config version and its peer dependencies. This feature may or may not land in 4.0 because it seems not that urgent.

@bodograumann
Copy link
Contributor

I would love to see that, @sodatea. I often have the problem that npm update installs a new version of typescript but @typescript-eslint/* are not updated. That leads to the usual “typescript version not supported” warning and to linting issues. Of course I can fix it with a deep update, but a more care-free solutions would be much appreciated.

@linden5
Copy link

linden5 commented Sep 9, 2019

How about supporting running vue-cli-service programatically by passing in user options?

@LinusBorg
Copy link
Member

Not sure what exactly you mean by that ...?

@linden5
Copy link

linden5 commented Sep 12, 2019

Not sure what exactly you mean by that ...?

The method "run" of vue-cli-service currently accepts three arguments: command, args, rawArgv. If there is a method to run the service by passing in a config object and an array of plugins, it would be more convenient for users who want to build their own cli tools based on vue-cli-service and put all config files in the very pakcage (Actually I have been assigned such a task, and want to reuse the webpack configuration of vue-cli-service). The method may be called like this:

const vueConfig = require('vue.config.js')
const plugins = [
    require('@vue/cli-plugin-babel'),
    require('@vue/cli-plugin-eslint'),
    require('@vue/cli-plugin-unit-jest')
]
service.run(vueConfig, plugins)

Now, in order to make my cli tool work, I have to set the
environment variables VUE_CLI_CONTEXT and VUE_CLI_SERVICE_CONFIG_PATH, as well as manully constructing args and rawArgv the "run" method needs. This approach can solve the problem, but it makes the code a little hard to understand for others.

That's why I am requesting such a feature. I hope that I've made myself clear.

@georgyfarniev
Copy link

Why vue-cli uses nightwatch instead of puppeteer? For running against multiple browsers?

@LinusBorg
Copy link
Member

LinusBorg commented Oct 2, 2019

Exactly.

If you want to run against chrome only, we offer Cypress.

If you prefer puppeteer, write a plugin for it :)

@CommanderXL
Copy link

Is there any possible to add a hook for developers to modify the README.md?

In most situations, we use vue-cli to create some projects with default README.md generated by the readme.md utility function.So we want to generate the README.md file with different content after a project created by vue-cli.

@bodograumann
Copy link
Contributor

Cf. #3547 @CommanderXL

@CommanderXL
Copy link

@bodograumann Well, I have seen that issue.So will it come to the vue-cli of v4? Or need us to do some pull request to accomplish this function?

@LinusBorg
Copy link
Member

it's now marked as "contribution welcome" so we would be happy to see a PR for this.

@georgyfarniev
Copy link

Hello folks, I see that vue-next uses rollup for build, so is there any plan to support it as alternative to webpack in vue-cli?

@LinusBorg
Copy link
Member

LinusBorg commented Oct 9, 2019

No. Supporting two build tools will increase complexity too much.

@georgyfarniev
Copy link

No. Supporting two build tools will increase complexity too much.

Agreed, thanks. So it will be used only for vue due to its simplicity

@sodatea
Copy link
Member Author

sodatea commented Oct 16, 2019

Released 🎉
The release note: https://github.com/vuejs/vue-cli/releases/tag/v4.0.0
The migration guide: https://cli.vuejs.org/migrating-from-v3/

@sodatea sodatea closed this as completed Oct 16, 2019
@sodatea sodatea unpinned this issue Oct 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests