4 ms·

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 opi

by leerob 5y ago

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_wizard 5y ago
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

by leerob 5y ago

no_wizard 5y ago

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