The origin story starts with this looongstanding open issue on TSDX from @n_moore. As an early helper on TSDX I shied away from it bc I thought that it should be solved by dedicated tooling like @yarnpkg.
Big monorepo shops like Facebook and Google have loads of tooling to make monorepos work, but this class of tooling never made it out into open source.
@TurboRepo does 3 things:
- Make monorepos zero config
- Make monorepos incrementally adoptable
- Make monorepos scale
- Read your build pipeline from `turbo` config in package.json
- Generate dependency graph
- Fingerprints inputs
- Executes each task in turn
- Caches output/logs
On subsequent runs, if a task matches a fingerprint, it restores from cache and replays logs.
The API surface area of @TurboRepo is shockingly small:
1️⃣`npx create-turbo@latest myrepo` scaffolds a new monorepo
2️⃣`turbo run build` runs the `build` task
3️⃣configure pipeline in package.json `turbo` key
The showstopper, still in beta, but the reason why @Vercel's acquisition makes total business sense (apart from gaining the imprimatur of having @jaredpalmer on staff).
- Efficient scheduler + rebuilder system ensures you never recompute work that has been done before
- Parallelize as much as possible
- 74% written in Go (see: "Systems core, Scripting shell" in Third Age thesis)
- "Zero config" - lots of value out of the box
- Declarative build pipeline
- Great debugging/profiling
- Great docs/marketing
- Devs have been hearing nonstop about the benefits of monorepos but always held back by tooling
For more on TurboRepo, including notes on future roadmap, check out my blogpost:
As a former monorepo skeptic, IMO this is the time to really dig into them as they are set to explode in 2022.
Added a section to give some spotlight to @NxDevTools as well, as @jeffbcross has been patiently answering questions in the replies. They have a comparison page up on their docs: nx.dev/l/r/guides/tur…
Trying out @factoriogame for the first time this weekend
If you don't hear from me... you'll know its going well
@factoriogame streaming it actually DM to jump on stream and chat if we know each other
Before I attempt the last tutorial I'm checking out a few tips and tricks videos to see what I'm doing suboptimally and there's a LOT! man, tutorial was good but I was doing so much manually that they could've just told me outright...
This year I've done a total 180 on open source strategy.
Remember Elastic making a fuss with "Amazon: NOT OK"? I was quite persuaded. If MongoDB, Redis, Cockroach, Confluent relicensed and do fine, maybe SSPL just becomes acceptable "open source".
Now I think MIT is just fine.
Probably my biggest test of confidence was in March when @martin_casado and @davidu pushed back on the open source religion - if your monetization is SaaS, then open source is just marketing (there's nuance here, pls read his replies before reacting)
Open sourcing has a cost - at @temporalio it impacts decisionmaking in engineering, product, docs, devrel. Tradeoffs we wouldn't have if we just had a free tier.
But look at how extensively @NetflixEng has been able to adapt our SDKs and devtools:
in fact i’m -so- not a perfshamer I shall now say the thing I’m not supposed to say:
before today you didnt know or care that Notion had a 9.1MB JS marketing site; if it impacted them enough they would’ve fixed it sooner; you may have a fast site but they have 10 million users.
- Delivery lead time
- Deployment frequency
- Mean time to restore service
- Change fail rate
What would the 4 key metrics of Dev Experience be?
my picks:
🌏 Time to World Tour
Anyone can do "Hello World" with `git clone` and not teach a thing. More impt to give the developer a useful mental model of what they should know in short time.
You can't visit all 192 countries, but you can show that there are 7 continents.
🏃♀️ Time to Implement Change
Anyone can build brittle systems. But great DX optimizes for 1-2 standard deviation changes in requirements:
- find helpful docs fast (better: no docs needed)
- low edit distance
- smooth migration paths