Distribute Esy along with Reason-CLI

[andreypopp]

DO NOT MERGE YET: let's have a discussion first

How does it work

1. Reason CLI release packages ship with a bundled Esy installation inside.
2. Reason CLI exposes esy executable which (a) optionally relocates Reason CLI artefacts and then (b) executes real a esy executable found in a bundled installation.

What does it mean optionally? It relocates only if ~/.esy isn't present, otherwise we assume that Esy is already installed (and most likely contain most of Reason CLI built artefacts) and do nothing. That means esy from Reason CLI is only useful for those users who didn't install esy themselves.

Why esy installation is bundled with the release packages?

The main reason not to use npm "dependencies" and depend on Esy in a regular way was that it's hard to locate the esy executable in that case (especially given the differences in global installs between npm and yarn).

One way would be to use node -p "require.resolve(...)" but that means imposing Node runtime startup toll on any esy invocation.

Also in case of a bundled Esy installation we still have no deps in reason-cli package. That means pack and bin releases still consist of a single tarball which can be installed offline. Though that might be less of an advantage as yarn/npm offline capabilities improved since (are they really?).

How esy installation is bundled

The way we bundle an Esy installation is a little bit hacky:

1. we do npm install -g --prefix _esyInstallation esy in release dir before packing it.
2. we produce a .tgz out of _esyInstallation

Why? npm doesn't allow to include node_modules directories (even nested ones) inside packages unless you have bundledDependencies but those don't work the same between npm and yarn.

Questions / notes

1. If esy package is installed then reason-cli release package will overwrite esy executable from the esy package.
2. There could be probably a better check performed to test if need to relocate Reason CLI artefacts to ~/.esy (now it checks just for the existence of ~/.esy). But such check should also be performant as it is performed on each invocation of esy.

[jordwalke]

I'll address all the questions/ideas, but a couple of quick thoughts that might address some of your concerns:

• To avoid naming conflicts, you could name the included esy esyc for "Esy canary" like npmc. If the main point of including it in reason-cli is to just let people get a preview of the wip. It also manages the expectations that it's still WIP.
• If you'd prefer to have esy be primarily its own managed installation, perhaps we could have the main esy install command check some known directory locations/patterns to see if there are resources that can be relocated. Release packages like reason-cli can in some cases help esy out by leaving a symlink "note" for esy to find in the home directory ~/esy/availableRelocations/reason-cli -> actualLocation. Often, reason-cli can't write to the home directory so that's a challenge. But in the cases when it can't write to the home directory, I would imagine that the install locations are pretty predictable. Just a thought. Can you think of any other easy-to-maintain way for installed packages to leave a "note" for the standaloneesy package to find?

[jordwalke]

It would be nice to have esy in reason-cli just to get it in peoples' hands, (and facilitate best-effort but not mandatory cache relocation), but without the downsides of getting in the way of another esy installation.
I wonder if we can get the best of both worlds:

• reason-cli can include an up to date esy embedded in it.
• We can probably figure out some good way to relocate the cache.
• reason-cli can expose its own esy binary, and esy itself can expose two binaries: esy and esy-actual which both point to the exact same thing. What if the reason-cli version of esy (in addition to whatever other special things we want it to do), firsts checks for the presence of esy-actual, and if it exists execs that, otherwise runs reason-cli's own version of esy.
  • This would handle the case when you had an esy install, and then you later installed reason-cli, which overwrote the esy binary, but not the esy-actual binary.
  • If you first install reason-cli, and then later install esy globally - reason-cli's own esy binary gets overwritten by esy's global esy binary. If the only thing that reason-cli's esy binary did was check for esy-actual, then this is perfectly fine.