fuelup

fuelup copied to clipboard

When working on a JS project, sourcing deps like forc and fuel-core is an issue. To make this easier, we can follow the example of other non-JS projects that want to play well with the JS ecosystem and release a package to NPM called fuelup-bin, so our toolchain can be a regular NPM dependency.

---

The initial plan was to release forc-bin and fuel-core-bin, but was closed in favor of fuelup-bin: https://github.com/FuelLabs/pm/issues/19

Some work was already done for forc-bin on https://github.com/FuelLabs/fuels-ts/pull/287 which can be repurposed for fuelup-bin.

To understand this issue a bit better, what would be the usage like after publishing fuelup to npm? As far as I understood from reading the linked PRs above (and your last comment here, there are 2 needs to fulfill:

1. JS projects need to be able to use forc and fuel-core and update them if necessary
2. the CI needs to be able to use forc

In the case of 2, would https://github.com/FuelLabs/action-fuel-toolchain be useful here?

This is what I imagine:

• We go to a TS repo
• We do npm add fuelup-bin which will install a specific version of fuelup locked by package-lock.json.
• Now we can do npm exec fuelup, npm exec forc and npm exec fuel-core because these are all binaries of fuelup-bin.
• At this point npm exec forc and npm exec fuel-core fails because we don't have them installed.
• We create a version file like .forc-version that will lock the version of forc (which will also depend on a specific version of fuel-core so its version will be locked too).
• Now we run npm exec fuelup install which sees our .forc-version and installs the correct versions to the correct places so npm exec forc and npm exec fuel-core works.
• Lastly we add fuelup install to our postinstall script so when a new dev (or the CI) clones the repo and does an npm install everything required will be automatically installed.

Emphasis on the "installs [to the] correct places" by the way. The meaning is that these should be local installs scoped to the project and not global installs. People shouldn't clone a fuelup-bin project and get their global installation messed up.

@AlicanC I think there's a chance you might not actually want the fuelup bin itself here.

fuelup itself has a very narrow scope, which is providing an easy way to get going with the necessary set of tools required for fuel dev, including fuel-core, forc and a curated set of forc-plugins. fuelup can be thought of as a very minimal package manager that purely ships fuellabs tools and installs them at $HOME/.fuelup/bin, with some convenience commands for switching between different version sets. This is quite useful as it means there's always a way for users to get started with Fuel dev, even if a user's OS or language package manager doesn't provide any of the fuel packages yet.

If other package managers (e.g nix, brew, npm, basel, whatever) plan to ship or integrate fuel-core and forc, they are very likely better off packaging each of these tools individually in their own way, as doing so will likely involve placing packages in certain standard paths, fetching them during some standard fetching stage, locking them, etc - all of which fuelup does in its own way.

One thing other package managers might find useful is the version compatibility index that fuelup's CI will eventually manage at this repo (not yet implemented). E.g. other package managers might benefit from using this to select compatible fuel tool version sets, but will likely want to fetch/build/lock/cache those themselves rather than doing so indirectly via fuelup.

That said I've not much experience with npm itself - let me know if I'm missing the point here!

@mitchmindtree "packaging each of these tools individually" was my thought when I opened https://github.com/FuelLabs/pm/issues/19.

@adlerjohn suggested we do this instead here: https://github.com/FuelLabs/pm/issues/19#issuecomment-1157069847

I'm ok with both and can't really decide.

(I've also set P: Low. This isn't a blocker or anything.)