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!

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

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)

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