fix(turborepo): Rationalize the install and execution process. (#5695)
Previously we had a lot of complexity in our install scripts inherited
from `esbuild`. This change removes _all_ of the incidental complexity
in favor of relying upon default ecosystem behaviors in most cases.
Instead of attempting correction of configuration at both installation
and invocation, it handles everything at invocation. Early returns
ensure that we perform the exact same amount of work as we did in the
previous variation.
It can now also detect and provide instructions on how to repair a
broken `package-lock.json` caused by
https://github.com/npm/cli/issues/4828. (Note: if the "just try
installing" [saving throw](https://en.wikipedia.org/wiki/Saving_throw)
works, we won't provide this information to the user. I elected this
ordering for startup time reasons.)
As an added bonus, `turbo` no longer has a `postinstall` script which is
more end-user-friendly.
Material changes:
- Does not attempt to extract turbo from a Yarn PnP without
`preferUnplugged` support. This works with _all_ stable releases of
`yarn` (berry). This is a change for users on canary versions
>2.0.0-rc.0 && <=2.0.0-rc.30 from September 2019 – March 2020—but we
already don't support in other portions of our codebase so this only
changes where the error is thrown from.
- In the event of `npm install` download failure it does not attempt to
directly download a tarball. If a user misconfigured their setup _and_
we didn't succeed at `npm install` to bail them out? It's okay for you
to get an error with lots of details on how to fix your configuration.