Turborepo 1.2: High-performance build system for monorepos • Hacker News Board

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

#51

Post by leerob » Mon, Apr 11, 2022, 1:25 AM UTC

no_wizard wrote: post #41

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?

If I'm hearing you correctly, your pain is having to configure ESLint manually, correct? Are you wishing for ESLint to be included in Turborepo natively? My opinion is that giving folks the option on their linter of choice is a good thing, even though ESLint is very popular.

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

#52

Post by leerob » Mon, Apr 11, 2022, 1:27 AM UTC

forty wrote: post #48

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…

Hey! Yeah, we recommend using pnpm. Excellent tool. You might be interested in this feature from 1.2:

"You can enable Turborepo to sign artifacts with a secret key before uploading them to the Remote Cache. Turborepo uses HMAC-SHA256 signatures on artifacts using a secret key you provide. Turborepo will verify the remote cache artifacts' integrity and authenticity when they're downloaded. Any artifacts that fail to verify will be ignored and treated as a cache miss by Turborepo"

https://turborepo.org/docs/features/remote-caching

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

#53

Post by leerob » Mon, Apr 11, 2022, 1:29 AM UTC

slively wrote: post #50

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 (b…

You can self-host your remote cache if you'd like. For example, with GitHub Actions. We're working on better docs for this.

https://turborepo.org/docs/features/remote-caching#custom-re...

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

#54

Post by no_wizard » Mon, Apr 11, 2022, 2:02 AM UTC

leerob wrote: post #51

no_wizard wrote: post #41

Earlier quoted context omitted.

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?

If I'm hearing you correctly, your pain is having to configure ESLint manually, correct? Are you wishing for ESLint to be included in Turborepo natively? My opinion is that giving folks the option on their linter of choice is a good thing, even though ESLint is very popular.

No, I’m saying I’d like to install eslint at the root of the repo and turbo could just spawn a process to use the root install of eslint for each package in the monorepo using the root config. Could do the same with prettier etc. just use a sub process to spawn and control the directories it runs against.

I’d like to see this for other tools too. I know turbo knows what the root of my repository is, this would make tools and reusabilty more efficient. It’s be even better if I could pass arbitrary arguments to actions like that so commands know where they are operating

It gets tiresome having to copy configuration and what not. Just less files to manage and less places to have to update things overtime.

It’s almost like you need gulp tasks again or something like that and the whole idea is to get away from task runners right? Yet I still need to manage my per package configs and pipelines on top of turbo

Turbo still forces you to have to think about so many other parts of the pipeline. At least nx has plugins but it’s support outside of their happy path for customizations is horrid, but turbo just lacks any thought to this problem of re usability on a task basis.

I don’t want to litter the package.json for each packages with every dependency they need to operate actions be it formatting, minting, etc because that means I have to check them all for different versions, make sure new packages have the same layout etc. A task runner like turbo should be aware enough to know how to do segmented task running by spawning processes for each package without needing a copy of whatever tool installed for each package

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

#55

Post by forty » Mon, Apr 11, 2022, 6:36 PM UTC

leerob wrote: post #52

forty wrote: post #48

Earlier quoted context omitted.

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…

Hey! Yeah, we recommend using pnpm. Excellent tool. You might be interested in this feature from 1.2: "You can enable Turborepo to sign artifacts with a secret key before uploading them to the Remote Cache. Turborepo uses HMAC-SHA256 signatures on artifacts using a secret key you provide. Turborepo will verify the remote cache artifacts' integrity and authenticity when they're downloaded. Any artifacts that fail to v…

HMAC are symmetric signatures, which means that anyone who can check the signature can also poison the cache (so pushing only from the CI are reading/checking on the dev machines would not be possible)