Load svgo version from project

[devongovett]

Closes #9045, closes #9935, fixes #8948, fixes #9660

This is another attempt at upgrading SVGO to v3. In order to avoid breaking changes, this moves the dependency from the Parcel plugin to the project. To handle the migration, we attempt to detect the version of SVGO needed by inspecting the config file and determining if any options that were removed in v3 are present. If so, we'll log a warning and install v2. Otherwise we will install v3.

This means that new projects, and existing projects with no config or a config compatible with v3, will be upgraded automatically by installing v3 into their project. Existing projects that are using deprecated options in v2 will install v2 into their project. From then on, Parcel will load svgo relative to the project root (as it probably should have all along).

[jakec-dev]

This seems to be a breaking change. We are no longer able to build as it creates error:

[BuildError: Could not resolve module "svgo" from "/builds/path/tot/index"] {
diagnostics: [
{
message: 'Could not resolve module "svgo" from "/builds/path/to/index"',
hints: [
'Autoinstall is disabled, please install this package manually and restart Parcel.'
],
origin: '@parcel/optimizer-svgo'
}
]

Issue only started happening after updating to 2.13.0

[jakec-dev]

Can confirm after rolling back to 2.12.0 with no other changes fixes the issue.

If SVGO is being removed from dependencies then should it not be put in as a peerDependency?

[devongovett]

The hint in the diagnostic you posted suggests that you turned off auto install, and so you need to manually install svgo into your project to fix the issue. Did you follow the suggestion?

Peer dependencies are not an option because we need to detect which major version of svgo to install based on the config file in order to prevent an actually breaking change (config file no longer works) while also allowing people to upgrade to the new version. Adding a peer dep of "svgo": "^2 || ^3" would result in v3 always being installed by default, breaking existing projects with old config files. That's why we had to rely on auto install for this.

[jakec-dev]

We haven't disabled auto install though. Our config is simply:

{
"extends": "@parcel/config-default",
"resolvers": [
"@parcel/resolver-glob",
"..."
]
}

initiated as

const bundler = new Parcel({
  entries: path.resolve(__dirname, '../src/client/index.html'),
  defaultConfig: '@parcel/config-default',
  mode,
  targets: {
    client: {
      context: 'browser',
      distDir: 'dist/client',
      isLibrary: false,
      scopeHoist: true,
      sourceMap: mode === 'development',
    },
  },
  shouldDisableCache: !isDev,
  ...(isDev && {
    hmrOptions: {
      port: 3000,
    },
  }),
  defaultTargetOptions: {
    publicUrl,
  },
});

Also as per my original comment, this is a breaking change not a minor update. To resolve this we now have to pin our version in package.json to 2.12.0. We can't use ^2.12.0 otherwise npm updates package-lock.json to 2.13.0 which is a breaking change.

[devongovett]

Ah, didn't know you were using Parcel programatically instead of via the CLI. In that case, you can enable auto install via the shouldAutoInstall option. Or, just install svgo in your project manually and it should be fixed. No need to pin anything.

Sorry it broke your build, but I hope you can appreciate the pickle we are in here. We can't not update svgo because it's already broken, in particular due already being updated in htmlnano, causing peer dependency errors on install (#8948). So we have to bump it, we can't use peer dependencies, we're not going to release Parcel v3.0 just for this, so trying to auto install the right version is our best option.

[kflorence]

Just wanted to note that this also broke my build upon upgrading from 2.12 -> 2.13. It seems that the svgo dependency must have not needed to be auto installed previously, and now it does, so it broke on the production build where auto install is disabled. Adding the svgo dependency to devDependencies fixed the problem.

[devongovett]

Yes, that is the expected upgrade path.