Upgrade: Install/Add Storybook dependencies the default way

[valentinpalkovic]

Closes #28569

What I did

With this change we are respecting the user's setting related to how dependencies should be saved to the package.json. The default behaviour is adding a caret to dependencies when added to the package.json. People can override this behaviour by defining them in, for example, a save-exact=true setting in their .npmrc file.

Checklist for Contributors

Testing

The changes in this PR are covered in the following automated tests:

• stories
• unit tests
• integration tests
• end-to-end tests

Manual testing

This section is mandatory for all contributions. If you believe no manual test is necessary, please state so explicitly. Thanks!

Documentation

• Add or update documentation reflecting your changes
• If you are deprecating/removing a feature, make sure to update
  MIGRATION.MD

Checklist for Maintainers

• When this PR is ready for testing, make sure to add ci:normal, ci:merged or ci:daily GH label to it to run a specific set of sandboxes. The particular set of sandboxes can be found in code/lib/cli/src/sandbox-templates.ts

• Make sure this PR contains one of the labels below:

  Available labels

  • bug: Internal changes that fixes incorrect behavior.
  • maintenance: User-facing maintenance tasks.
  • dependencies: Upgrading (sometimes downgrading) dependencies.
  • build: Internal-facing build tooling & test updates. Will not show up in release changelog.
  • cleanup: Minor cleanup style change. Will not show up in release changelog.
  • documentation: Documentation only changes. Will not show up in release changelog.
  • feature request: Introducing a new feature.
  • BREAKING CHANGE: Changes that break compatibility in some way with current major version.
  • other: Changes that don't fit in the above categories.

🦋 Canary release

This PR does not have a canary release associated. You can request a canary release of this pull request by mentioning the @storybookjs/core team here.

core team members can create a canary release here or locally with gh workflow run --repo storybookjs/storybook canary-release-pr.yml --field pr=<PR_NUMBER>

name	before	after	diff	%
createTime	23.2s	7.1s	-16s -166ms	🔰-227.3%
generateTime	22.8s	24.8s	1.9s	🔺7.8%
initTime	23.9s	25.6s	1.6s	🔺6.5%
createSize	0 B	0 B	0 B	-
generateSize	76.5 MB	76.5 MB	0 B	0%
initSize	198 MB	198 MB	-601 B	0%
diffSize	122 MB	122 MB	-601 B	0%
buildTime	15.8s	15.2s	-563ms	-3.7%
buildSize	7.59 MB	7.59 MB	0 B	0%
buildSbAddonsSize	1.63 MB	1.63 MB	0 B	0%
buildSbCommonSize	195 kB	195 kB	0 B	0%
buildSbManagerSize	2.3 MB	2.3 MB	0 B	0%
buildSbPreviewSize	349 kB	349 kB	0 B	0%
buildStaticSize	0 B	0 B	0 B	-
buildPrebuildSize	4.47 MB	4.47 MB	0 B	0%
buildPreviewSize	3.12 MB	3.12 MB	0 B	0%
testBuildTime	0ms	0ms	0ms	-
testBuildSize	0 B	0 B	0 B	-
testBuildSbAddonsSize	0 B	0 B	0 B	-
testBuildSbCommonSize	0 B	0 B	0 B	-
testBuildSbManagerSize	0 B	0 B	0 B	-
testBuildSbPreviewSize	0 B	0 B	0 B	-
testBuildStaticSize	0 B	0 B	0 B	-
testBuildPrebuildSize	0 B	0 B	0 B	-
testBuildPreviewSize	0 B	0 B	0 B	-
devPreviewResponsive	8.6s	9s	371ms	4.1%
devManagerResponsive	5.7s	5.7s	18ms	0.3%
devManagerHeaderVisible	917ms	847ms	-70ms	🔰-8.3%
devManagerIndexVisible	944ms	891ms	-53ms	🔰-5.9%
devStoryVisibleUncached	1.4s	1.4s	-79ms	🔰-5.6%
devStoryVisible	969ms	920ms	-49ms	🔰-5.3%
devAutodocsVisible	787ms	689ms	-98ms	🔰-14.2%
devMDXVisible	743ms	760ms	17ms	2.2%
buildManagerHeaderVisible	780ms	677ms	-103ms	🔰-15.2%
buildManagerIndexVisible	783ms	680ms	-103ms	🔰-15.1%
buildStoryVisible	840ms	726ms	-114ms	🔰-15.7%
buildAutodocsVisible	732ms	650ms	-82ms	🔰-12.6%
buildMDXVisible	711ms	790ms	79ms	🔺10%

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 1c5424b. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this CI Pipeline Execution

---

✅ Successfully ran 1 target

• nx run-many -t build --parallel=3

---

Sent with 💌 from NxCloud.

[ndelangen]

See here:
#28579 (review)

When @yannbf was testing the behavior on his machine we observed yarn behave very differently from when we tested a similar command on your machine with npm.

The problem is that package managers do different things.
npm will install the exact version, in the lockfile, but add a caret in the package.json file
yarn however, will add the exact version to the package.json`.

The industry standard is to have ^ ranges in package.json and ensure versions do not drift unexpectedly using lockfiles.
We want to ensure this behavior is held true, for all package managers.

Here's why me and @JReinhold ended up with the code above:

• In the case of @latest isCLIOutdated will be false, and isCanary will be false too.
  Meaning we add the ^ and manually write that to the package.json
  We can safely do this, because latest is latest, the subsequent install command will install the same version, because nothing higher can exist.
• In the case of someone installing @next, both will be false again. Actually that behavior might be wrong. The caret will be added, meaning you might get a later alpha then you asked for.
• In the case of a canary, the isCanary will be true, and no caret will be added.
  Due to this being manually written to package.json, the behavior from all the package manager will be consistent.
• In the case of an specific version, the isCLIOutdated will be true, and cause the ^ not to be printed.

I hope this explains a bit why it was chosen to manually write to package.json, instead of letting them do as they do... their behavior is inconsistent, and the upgrade experience would be different between using npm and yarn.

If we're going to fix the bug here: #28569
..then we need to make absolutely sure, that the upgrade behavior is as is expected in every package manager we support.

The code below will not do that.