chore: use hoisted yarn install in build binary

[tgriesser]

Additional details

Runs the "yarn install" from the root of the packages to de-duplicate node requires via hoisting. Reduces the overall bundle size by a considerable margin >100mb, and the compressed app by ~50mb.

Main changes:

• Moved install path to path.join(os.tmpdir(), 'cypress-build', PLATFORM) with a symlink to build in the root for convenience (per @brian-mann request)
• Loosen semver ranges from pinned to ^ for better deduplication of dependencies
• Copy yarn.lock from the root before yarn --production to ensure we are building with the same dependencies we have in the lockfile for develop/testing (allows us to use the ^ rather than pinned versions with more confidence)
• Removes additional unused directories or files demo / test that are taking up space, primarily in image libraries

How has the user experience changed?

• Smaller bundle
• Faster install time

Before:

After:

PR Tasks

• Have tests been added/updated?

[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

4125 • 0 • 50 • 2 • 0

---

Run details

Project	cypress
Status	Passed
Commit	ce28486
Started	Jul 6, 2021 2:18 PM
Ended	Jul 6, 2021 2:28 PM
Duration	10:22 💡
OS	Linux Debian - 10.8
Browser	Chrome beta 92

View run in Cypress Dashboard ➡️

---

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

[lmiller1990]

I do not 100% comprehend everything that's going on here, but I gave it a test - ran the commands - and the size is indeed smaller, like Tim says in the description.

Probably good to get a second set of eyes on the code, but it looks like there's been a decent amount of internal discussion already.

[thlorenz]

LGTM except I have reservations with build script being TypeScript, i.e. to do the build you need to first build the scripts doing that (or at least on the fly).

I've been just adding // @ts-check on top of files involved in any kind of devops/building or whatever needed to prepare artifacts, i.e. https://github.com/thlorenz/cypress/blob/thlorenz/develop-ts/packages/ts/build-ts.js#L1.

You could go even further with that and add type annotations which are actually checked as well. See this example: https://github.com/thlorenz/cypress/blob/snapshot-8.0-release/packages/snapshot/snapconfig.js#L33-L65
Obviously only if desired, // @ts-check alone already goes a long way.

This provides sufficient warnings IMHO to not waste time discovering mistakes at runtime while keeping the build requirement to just having Node.js installed and ready.

[tgriesser]

@thlorenz yeah it does build on the fly here with ts-node, and this script is only run when building the binary. It takes several minutes to execute (does a full production build of all modules / production yarn install / full electron bundle), so the relative overhead of transpiling on the fly is almost zero.

This provides sufficient warnings IMHO to not waste time discovering mistakes at runtime while keeping the build requirement to just having Node.js installed and ready.

Potentially, though you'd also need all of the dependencies it references installed, meaning you'd still need the yarn install

I could go either way though, I sort of think if we're trying to move more things to use .ts it's better to be consistent, but I could be convinced to keep it in .js if you still think it should be moved given the above. FWIW I think your example is potentially better suited in .js for the reasons you noted and b/c it's run more frequently.

[thlorenz]

@tgriesser I'm not concerned about the transpile cost, merely that now you need to have ts-node installed additionally to just Node.js.
However if we're all good with that and given we install ts-node as dev dependency then it might be ok.

It's more opinion than anything same reason why people should limit bash scripts to bash features instead of requiring zsh or similar.

If you feel .ts buys you a lot more than a ts-check could then let's agree to allow typescript in build scripts.
I might then write mine in TS as well in the future :)

[thlorenz]

As per discussion in Slack we agreed that TS for build scripts is fine and we should keep writing scripts in TypeScript going forward. The only exceptions are when scripts somehow execute at runtime or for our users or are very performance sensitive.