chore: revamping build tooling

[arboleya]

Summary

• Close Make it possible to use local fuels build #834

This PR thoroughly revises the current build system, double-checks configs, rules, and caching mechanisms, removes tsup in favor of good old tsc, fulfills all requirements from #834, and does a few extra optimizations here and there.

I will try to outline the main ones.

Local install (TL;DR)

More notably, you can now install and run your local versions of fuels.

This was the primary motivation that drove everything else.

cd your-app
pnpm add ~/my/local/fuel-ts/packages/fuels

Remember to build first

Since our packages export Javascript files now, we need to build the packages after each change we make. Otherwise, we'd still be looking at outdated compiled Javascript files. To automate this, you can run the following:

# on repo root
pnpm dev

This will pnpm build the project once, then watch and re-build it automatically on every change. It uses nodemon to watch all packages simultaneously for optimum performance. The building part continues to be handled by Turbo Repo.

Go to Definition

To make it possible to export Javascript files and have a local working fuels package while still being able to go to definition inside our Typescript source files, we had to generate declarationMaps in our build routine:

• https://www.typescriptlang.org/tsconfig#declarationMap

DeclarationMaps are SourceMaps for DTS files; they map it back to their source *.ts file.

This is the secret hidden part.

Yes compile, no bundling

Because tsup can't generate declarationMaps, it was replaced by good ol' tsc, which means:

• We are not bundling our code anymore

Bundling was a feature of tsup, which tsc doesn't do.

All packages are still published in CJS and ESM formats, but now as multiple individual files mirroring the source directory structure instead of a single .js file. Frontend frameworks can easily tree-shake it as part of their bundling.

Forc optimizations

Every time you do a pnpm install, it triggers a preinstall routine for packages/forc-bin that will would download all Forc binaries. Again. All the time. Starting now, it first checks if it needs to download Forc and skips otherwise.

Build optimizations

In the middle of every pnpm build for the example-contract package, it would trigger a pnpm install again. Since we use pnpm w/ workspaces, that install would occur on the repo root. Triggering preinstall hooks again, re-downloading Forc, and all that good stuff. It would delay the build by around ~10s or so, but not anymore.

Note I suspect this inner pnpm install could be causing those text: busy errors. (@Dhaiwat10 @camsjams)

Before:

fuels-ts/packages/example-contract/package.json

Line 8 in dd7b1ca

"build": "./scripts/build.sh"

fuels-ts/packages/example-contract/scripts/build.sh

Lines 5 to 9 in dd7b1ca

	# We run install again to make sure `fuels typegen` CLI is correct setup
	# this issue ocorrus becuase the CLI tool is under the same monorepo
	pnpm install
	pnpm forc build
	pnpm fuels typegen -i out/debug/example-contract-abi.json -o src/example-contract-types

After:

fuels-ts/packages/example-contract/package.json

Lines 8 to 10 in 1c5c22f

	"build": "run-s build:forc build:types",
	"build:forc": "pnpm forc build",
	"build:types": "node ./node_modules/fuels/dist/cjs/bin.js typegen -i out/debug/example-contract-abi.json -o src/example-contract-types"

Referencing the fuels typegen command using its full path circumvents the fact that the fuels symlink might not have been created yet, during the first pnpm install (which must be run right before the first build).

• Why does this happen?

Because at first, our bin entries ^{"bin": "dist/bin.js"} are not pointing anywhere because the packages were not compiled yet and the JS files don't exist. We first pnpm install and then pnpm build. But the install tries to create the symlinks for the files that will only exist after the first time pnpm build is run.

The last workaround was doing an npm install only to recreate these symlinks.

Stop running tests twice

Instead of running tests twice for each PR (for computing coverage diffs between the base branch and the PR), we now save the base branch coverage as an artifact and download it on each PR, cutting test time in half.

Final Notes

Worths mentioning:

1. Local builds are a bit faster
2. Local dev mode (build-watch) is lot faster
3. CI build & test routines combined are ~3mins faster

Total CI time for build + test:

Current on master	~15m ~12m
After this PR	~11m ~6m
Goal	<5m

More PRs to come.

[arboleya]

Note I'm marking this PR as a draft, as I'm currently dismembering it into several smaller ones. I'll make sure to close it once I finish this process.

[arboleya]

Every improvement from this PR has been independently merged already.

The final missing piece is here:

• feat: make packages usable locally #984

So I'm closing this one.