* feat: support binary mirrors for taobao registry
fixes issues like #4718
* fix: only install cypress 3, for now
* fix: do not override user defined `CYPRESS_INSTALL_BINARY` env
* fix: add pnpm v4 support
in pnpm v4 the option '--loglevel' is no longer available instead '--reporter' is used.
* refactor: remove 'v' from PNPM constants for linting
* refactor: rename variable
* fix: typo in _hasPnpm4orLater
Co-Authored-By: Pavan Kumar Sunkara <pavan.sss1991@gmail.com>
* refactor: reduce the amount of duplicate code for pnpm version check
* refactor: remove return-assignment
* refactor: add explicit return value instead of using array access
Co-Authored-By: Pavan Kumar Sunkara <pavan.sss1991@gmail.com>
* fix: remove return value from checkPnpmVersion
* fix: pnpmVersion variable
* refactor: cache pnpm version number
* refactor: fix function name and revert api break
* fix: function call correction
* refactor: export hasPnpmVersionOrLater and use this in favor of hasPnpm4OrLater
* refactor: move cache getter into getPnpmVersion
* refactor: add comment
* refactor: remove comment
It has become a common source of mistakes.
For example, during PR #4363 I've referred to the wrong `options`
several times due to the variable shadowing.
* refactor: move router to its own plugin
* refactor: rename routerHistoryMode option to historyMode
* test: add @vue/cli-plugin-router tests
* feat: change src/router.js for most common use cases
* fix: fix cli-ui tests
* docs: Remove router root option from docs
* fix: add support for legacy router option
The root cause here is the same as #4095
The failing `loadModule` call will return `undefined` for a js config
read operation, which later caused config being overwritten.
BREAKING CHANGE:
Preset generated before v3.4.0 may contain a `"cssPreprocessor": "sass"`
field. It now means dart-sass rather than node-sass.
`rootOptions.cssPreprocessor === 'sass'` now also means dart sass.
May affect those generator plugins who depends on this field
## Summary
- Keep package minors in sync (`lerna publish --force-publish` when releasing a new minor)
- Patch on demand (`lerna publish` fixed mode)
- `eslint-config-*` packages are published manually
## Longer Description
1. We used to force publish every package till v3.1, this is due to the unbalanced update frequency among different plugins. In practice, some of them, like the pwa plugin, are quite stable and rarely need updating. So force publishing is overkill now.
2. We have switched to independent mode then, for two major benefits: 1) patching on demand and only on demand 2) eslint config packages needs a more aggressive update strategy in practice, due to the frequent breaking changes in the upstream packages. However, this also causes maintenance burden and confusion to end users. So it's far from ideal.
3. So now we choose to go back fixed versioning. By default lerna would skip untouched packages when publishing a new version. This might be confusing as we think. So to reduce the cognitive load, we still keep each package's minor field in sync.
## Implementation Detail
1. To selectively publish packages, we have to disable `useWorkspaces` in lerna so that these packages can be linked by yarn while being unrecognizable to lerna.
2. Due to an oversight in the old version checking code, version fields in `vue-cli-version-marker` needs to be exact versions, otherwise cli will throw on startup. So we have to publish `vue-cli-version-marker` manually after other package updates. This logic can be removed once all users have been upgrade to 3.2.0+ and we can then add it back to `packages` in `lerna.json`
3. We now use `~/.vuerc` to cache version check results. This also fixes#2956
Now that lerna independent mode is used to release new versions, we can
no longer ensure the core service/plugin versions are in sync with
@vue/cli itself. So `vue-cli-version-marker` is now used to store the
latest version map of core packages.
In order to automate this process, all the core cli packages are listed
as `devDependencies` of `vue-cli-version-marker`. This will cause a
cyclic dependency warning in lerna bootstrap, and that warning can be
safely ignored because these are just `devDependencies` which won't
affect end users.
Another gotcha is that the version of `vue-cli-version-marker` will be
bumped each time we do a release. This may break the remote version
check logic before rc.12 (due to
https://github.com/vuejs/vue-cli/commit/1ae223dfc0a915513a3eff35c9d74fe6b5480224#diff-ac5fc3f8b11df9fc948b8e5aa52a074e
the background version check might never get executed since rc.12)
Haoqun Jiang