fix(cli): don't include workspaces.nohoist in public NPM package

[flotwig]

• Closes nohoist config is ignored #22147

User facing changelog

Fixed an issue causing a "nohoist config is ignored" warning when installing cypress with yarn.

Additional details

Steps to test

Install latest prerelease comment on this branch on Linux, note there is no warning.

How has the user experience changed?

PR Tasks

• Have tests been added/updated?
• Has the original issue (or this PR, if no issue exists) been tagged with a release in ZenHub? (user-facing changes only)
• [na] Has a PR for user-facing changes been opened in cypress-documentation?
• [na] Have API changes been updated in the type definitions?

[cypress-bot]

Thanks for taking the time to open a PR!

• Create a Draft Pull Request if your PR is not ready for review. Mark the PR as Ready for Review when you're ready for a Cypress team member to review the PR.
• Become familiar with the Code Review Checklist for guidelines on coding standards and what needs to be done before a PR can be merged.

[cypress]

---

Test summary

37553 • 0 • 454 • 0 • 2

---

Run details

Project	cypress
Status	Passed
Commit	0462489
Started	Jun 16, 2022 7:38 PM
Ended	Jun 16, 2022 7:56 PM
Duration	17:19 💡
OS	Linux Debian - 10.11
Browser	Multiple

View run in Cypress Dashboard ➡️

---

Flakiness

	cypress/e2e/cypress/proxy-logging.cy.ts		2
1	Proxy Logging > request logging > xhr log has response body/status code when xhr response is logged second
2	Proxy Logging > request logging > xhr log has response body/status code when xhr response is logged second

---

This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard

[ryanthemanuel]

Looks good. Is there a way to write a test for this change?

[flotwig]

@ryanthemanuel I don't see an obvious way to test it since it's in the build step. I could add an assertion in buiild.js or post-build.js, but it would be overly unit testy imo.

I think this script should be updated in general, we shouldn't need to do all this wacky merging of 2 package.jsons, I think all of the should be all in one place as much as possible. So no _.extend(json. We'd be better off since changes to cli/package.json couldn't have this unintended impact.

[ryanthemanuel]

@ryanthemanuel I don't see an obvious way to test it since it's in the build step. I could add an assertion in buiild.js or post-build.js, but it would be overly unit testy imo.

I figured as such. Approved!

[ryanthemanuel]

Looks good!