Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Turborepo 1.2: High-performance build system for monorepos

turborepo.org

Post reply on HN
Print view View original

41–50 of 55 posts

Re: Turborepo 1.2: High-performance build system for monorepos

#41

Post by no_wizard »

leerob wrote: post #2

Hey! In case you missed it, Turborepo launched 1.0 a few months ago[1]. This 1.2 release is important, as it includes --filter[2] (highly requested). You're able to much more easily filter tasks, instead of the previous --scope, --include-dependencies, --since, and --no-deps flags. Happy to answer any questions about Turborepo or monorepos in general (recently wrote an entire post about them[3]). [1]: https://turbore…

any way you're going to solve the linting problem? I had having to install eslint and produce a config on every little package in my repository.

Yes I can use a generator to handle this and other boilerplate, but why? Can't turbo just spawn eslint in sub processes to lint each package and stitch the input back together?

Re: Turborepo 1.2: High-performance build system for monorepos

#42

Post by wdb »

leerob wrote: post #12
bastardoperator wrote: post #8

I'm working with some fairly large monorepos and compile times. To be completely honest, JS is the least of our concerns when it comes to build time, things are pretty snappy when compared to other code bases like C, and Java even with tools like Bazel.

While we're initially focused on JavaScript and TypeScript codebases, you can already use Turborepo with any language as long as you define tasks through `package.json` scripts and use npm/pnpm/yarn workspaces. Turborepo is written in Go and uses `turbo` to build `turbo` in its own monorepo[1]. We're discussing more native support for other languages. It would likely be a commitment to a small subset of popular langu…

Please consider .net / msbuild support too :)

Re: Turborepo 1.2: High-performance build system for monorepos

#43

Post by pleasegod123 »

palmdeezy wrote: post #11
steven-xu wrote: post #7

Well done and congrats to the Turborepo team on the launch as well as the Vercel merger, which I think is a great thing for the JS ecosystem! We now have a healthy competition between several JS domain-specific build tools bit.dev, Nx, Turborepo, and Rush. This is in addition to plugins to general purpose monorepo tooling like rules_nodejs (Bazel). I'm looking forward to the seeing the new ideas that come out from th…

> There are a huge number of mostly non-JS-specific problems that monorepo tooling eventually needs to solve: distributed build artifact and test result caching, distributed action execution, sandboxing, resource management and queuing, observability, and integration with other CI tools to name a few. Turborepo author/founder here.... I agree. I built Turborepo because existing tools weren’t meeting our needs. To sol…

Hey. Off topic but would you consider handing Formik and TSDX to a community member? Huge appreciation for turborepo and your work on these other libraries -- they have become key parts of the ecosystem and turborepo could follow.

However, this is all the more reason why it could be super helpful to address the governance issue on those projects. Thanks and sorry for disturbing!

Re: Turborepo 1.2: High-performance build system for monorepos

#44

Post by darepublic »

steven-xu wrote: post #7

Well done and congrats to the Turborepo team on the launch as well as the Vercel merger, which I think is a great thing for the JS ecosystem! We now have a healthy competition between several JS domain-specific build tools bit.dev, Nx, Turborepo, and Rush. This is in addition to plugins to general purpose monorepo tooling like rules_nodejs (Bazel). I'm looking forward to the seeing the new ideas that come out from th…

I like github actions better than learning a new monorepo framework

Re: Turborepo 1.2: High-performance build system for monorepos

#46

Post by ceeplusplus »

qbasic_forever wrote: post #20
krapp wrote: post #19

Earlier quoted context omitted.

>I'm sad JS needs a build step. The best build system is none at all IMHO. Good news: JS doesn't need a build step. Modern webdev wants a build step mostly because it wants Javascript to feel more like a "serious" language. There are technical benefits to compiling to Javascript, most of which can be served by other means, but the unnecessary complexity of the Javascript ecosystem is mostly about gatekeeping and aest…

I'm with you in that a lot of TS use seems dogmatic or ritualistic today. I have a strong feeling in the near future we're going to see the bow string snap back and simple zero build, basic dynamic use of pure JS comes back in vogue.

TS is about readability and maintainability of code at scale. Having types helps immensely in understanding a new codebase and working in a large codebase with many other people.

Re: Turborepo 1.2: High-performance build system for monorepos

#47

Post by tehbeard »

krapp wrote: post #19
qbasic_forever wrote: post #16

Earlier quoted context omitted.

I'm sad JS needs a build step. The best build system is none at all IMHO. I'd love to see native support everywhere for typescript or other things we typically depend on a build for today.

>I'm sad JS needs a build step. The best build system is none at all IMHO. Good news: JS doesn't need a build step. Modern webdev wants a build step mostly because it wants Javascript to feel more like a "serious" language. There are technical benefits to compiling to Javascript, most of which can be served by other means, but the unnecessary complexity of the Javascript ecosystem is mostly about gatekeeping and aest…

> Typescript is part of the problem

Typescript is a solution to the jank-fucking-tastic type munging JS does (see: [1] About 1:20 in) and the problems that ensue.... if all you are doing is just making menus appear/disappear on click, by all means keep to JS.

The build steps/tooling are useful when you want to build actual applications rather than decorate a marketing page, and also when you need to support legacy browsers, being able to work with modern sensibilities and get code that'll work in IE11 is a blessing.

> the unnecessary complexity of the Javascript ecosystem is mostly about gatekeeping and aesthetics and i will die on that hill.

JS has much more of a "flavour of the week" problem than more mature ecosystems like PHP, I put that down to a relatively poor stdlib by comparison, rather than aesthetics or gatekeeping.

    1. https://www.destroyallsoftware.com/talks/wat

Re: Turborepo 1.2: High-performance build system for monorepos

#48

Post by forty »

leerob wrote: post #2

Hey! In case you missed it, Turborepo launched 1.0 a few months ago[1]. This 1.2 release is important, as it includes --filter[2] (highly requested). You're able to much more easily filter tasks, instead of the previous --scope, --include-dependencies, --since, and --no-deps flags. Happy to answer any questions about Turborepo or monorepos in general (recently wrote an entire post about them[3]). [1]: https://turbore…

Hello! We are using pnpm (which as I understand it has some overlap with what turborepo can do when it comes to monorepo management).

Some teams are considering turborepo for the remote caching feature. I'm a security guy, and I'm a little worried that remote caching basically means that all dev are able to run arbitrary code on other devs computer (by poising the cache). Am I missing something? Or are there security workarounds? Would, for example, only allow master build from the CI to push to the remote cache and only read only access for the devs work and still provide enough benefits? (I expect most dev to branch from master, so I'd assume the cache would be good enough?)

Thanks and congrats on the release!

Re: Turborepo 1.2: High-performance build system for monorepos

#49

Post by krapp »

ceeplusplus wrote: post #46
qbasic_forever wrote: post #20

Earlier quoted context omitted.

I'm with you in that a lot of TS use seems dogmatic or ritualistic today. I have a strong feeling in the near future we're going to see the bow string snap back and simple zero build, basic dynamic use of pure JS comes back in vogue.

TS is about readability and maintainability of code at scale. Having types helps immensely in understanding a new codebase and working in a large codebase with many other people.

The problem is Javascript has been entirely commoditized by enterprise, so solutions which should only be relevant to "code at scale" have become mandatory at any scale. You practically can't distribute a Javascript library without writing it in Typescript and submitting it to NPM, with the build step expected.

Yet writing even complex javascript without Typescript and having it work is still entirely possible, just as it is with other weakly typed languages. There should still be room for that, but the concept of simply writing javascript has become so alien it needs to be reintroduced as "vanilla javascript."

Re: Turborepo 1.2: High-performance build system for monorepos

#50

Post by slively »

I’ve been wanting something like this but there’s a few big things that stick out to me. Why is it configured via json instead of scripting? Declarative task/build tools are just not as nice as something where you can write code. Specifying a task input/output seems very limited and is where so much optimization comes from. The remote cache seems to only be available through some hosted service?

I use Gradle a lot (bazel a little) and would love a tool that’s got an api that’s easier to understand, but this seems like 100 steps backwards without a good path forward.

Post reply on HN