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
1ae223dfc0 (diff-ac5fc3f8b11df9fc948b8e5aa52a074e)
the background version check might never get executed since rc.12)
