build: turborepo #669
build: turborepo #669
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
refactor: change docs package.json private to false fix: build:docs fix: testing suite required jest-environment-jsdom with newer versions of jest refactor: run tests through turbo chore: turbo other tasks
chore: remove quotes around "private" chore: run sort-package-json chore: seems like vercel might need this path chore: clean up changes, make install scripts hidden chore: remove extra code from turbo file chore: sleepy rebase
This reverts commit 8d6262f.
| path: .turbo | ||
| key: ${{ runner.os }}-turbo-${{ github.sha }} | ||
| restore-keys: | | ||
| ${{ runner.os }}-turbo- |
There was a problem hiding this comment.
pulled this from vercel/turborepo#2761
but runner.os being the only unique key for the cache seems a little aggressive? is turbo smart enough to figure out what cached things to use across all our builds/commits?
There was a problem hiding this comment.
I forked austinwoon's demo, took a look at his commits and recreated his build examples so I could view the logs. I think turbo is smart enough to cache properly with the runner.os restore-key.
Turbo acts as if it would on your local machine. It performs a check to see if the cache is relevant. If changes are made it will build that specific package rather than using the cache.
There was a problem hiding this comment.
Branch name might be useful though because in the case two people are committing at the same time they will be fighting over the cache. According to the docs, multiple restore-keys can be provided and act as fallback keys on miss, so maybe it'd be good to take advantage of that.
|
cc @Handfish |
| "commit": "cz", | ||
| "dev": "turbo run dev --concurrency 20", |
There was a problem hiding this comment.
I'm curious how this works / is supposed to work. It seems like it runs dev independently for each package, so if I for example change things in world, only world rebuilds, but I would have expected all downstream dependencies (eg cli) to also rebuild? or is this not the intention of this command?
There was a problem hiding this comment.
Related to the comment above (but not strictly related to this PR) - should we add forge build --watch to the dev commands of our contract packages to rebuild those too (so in the ideal case a rebuild of downstream dependencies, eg CLI or network, would be triggered)?
There was a problem hiding this comment.
It seems like it runs dev independently for each package, so if I for example change things in world, only world rebuilds, but I would have expected all downstream dependencies (eg cli) to also rebuild? or is this not the intention of this command?
I'm not sure (first time using turbo/nx) but this is what I'd expect too, and something we can iterate on/improve as we go!
should we add forge build --watch to the dev commands of our contract packages to rebuild those too (so in the ideal case a rebuild of downstream dependencies, eg CLI or network, would be triggered)
Probably! But there are other things ahead of forge build that don't have watch commands yet like tablegen, worldgen, etc. so I was kinda waiting on those first. But again, we can improve this as we go.
There was a problem hiding this comment.
But there are other things ahead of forge build that don't have watch commands yet like tablegen, worldgen, etc. so I was kinda waiting on those first.
Agree those need --watch too, but forge build --watch could be useful by itself for all solidity changes that don't impact the interface and mud config
|
FYI, looks like Vercel attempts to detect turbo.json and uses
I'll follow up soon to see if docs can safely move back into the workspace. |
|
Very nice! |
| # https://github.com/foundry-rs/foundry/issues/4736 | ||
| - name: Install solc | ||
| shell: bash | ||
| run: cargo install svm-rs && svm install 0.8.13 |
There was a problem hiding this comment.
continues #661
vercel deploy fix in #674, will bring that in once merged