turbo icon indicating copy to clipboard operation
turbo copied to clipboard

Execute Arbitrary `package.json` Scripts

Open ObliviousHarmony opened this issue 2 years ago • 3 comments

Describe the feature you'd like to request

Right now you are given an error message when you attempt to execute turbo run using a command that is not a pipeline in your turbo.json file. With our pnpm workspace we have to use both pnpm {command} --filter={package} and turbo run {command} --filter={package} depending on whether or not a command exists within a pipeline. It would be great if we could use a single tool for all of our commands.

As an aside, the error message:

failed to resolve targets: task test:js not found in turbo pipeline in package.json. Are you sure you added it?

Seems to indicate pipelines used to live in the root package.json. Should that be updated?

Describe the solution you'd like

Since turbo just executes package.json scripts as tasks, it would be convenient if it could execute arbitrary commands. This would default to "cache": false since there is no pipeline definition. The main issue I see with this would be ambiguity about whether or not a command was being executed as a pipeline or arbitrarily. I think that's fine though since it would give the message that it isn't using a cache due to configuration.

The other benefit here is that we'd get to use the comprehensive package filtering functionality on any script. A single syntax for running commands in a monorepo!

Describe alternatives you've considered

An alternative would be to just add every single possible package.json script from any package to the turbo.json. I believe this is unreasonable, however, since that could be a very large amount of variability. I do think this is a good way to enforce consistency to avoid accidents but it seems unnecessary.

ObliviousHarmony avatar May 17 '22 23:05 ObliviousHarmony

I think with a reasonable set of defaults (no dependencies, no caching), this could work.

gsoltis avatar May 27 '22 23:05 gsoltis

@gsoltis Would it be possible to still support the dependency traversal provided by the --filter syntax using the ... token?

ObliviousHarmony avatar May 31 '22 22:05 ObliviousHarmony

I think so. As long as we can get dependencies from package.json, I don't see why not.

gsoltis avatar Jun 01 '22 20:06 gsoltis