Replies: 3 comments 1 reply
-
Oh this is a great idea, just came here to open a similar case. We are switching form monolith to monorepo currently because we will build multiple ionic-capacitor apps in one project (custom branded for our customers). At the moment I am using npm-run-all in the root with |
Beta Was this translation helpful? Give feedback.
-
I think this feature is very useful, imaging that you have 20 package in monorepo, each package have 5 commands in script such as "dev, build, lint, clean, watch", and each of them are same command just in different package, so can we just support "extends" method just like tsconfig.json did? that gives more flexibility to developer for big monorepo. |
Beta Was this translation helpful? Give feedback.
-
What about adding packages:
- 'ui/**/*'
catalog:
snabbdom: ^3.5.1
'@badrap/result': ^0.2
scripts:
type-check: 'tsc --noEmit'
lint: 'eslint . --ext .ts' Each workspace "scripts": {
"lint": "scripts:",
"type-check": "scripts:"
}, Scripts would still need to be listed in each workspace, but it has similar advantages as catalogs and the same syntax. |
Beta Was this translation helpful? Give feedback.
-
In the pnpm monorepo, we copy/paste the same scripts to almost every project. There should be a better way to do this.
Yarn solved this with constraints. For instance, this is how they generate the prepack scripts:
https://github.com/yarnpkg/berry/blob/20a3fdfe6ef88bf611a5b3af21abe24c86add204/constraints.pro#L62-L69
We don't have constraints support though. And seems like not everyone is currently happy with Yarn's constraints, as they are written in Prolog.
Maybe we could come up with something like a "baseScripts", which are inherited by each workspace project.
related: #1813
Beta Was this translation helpful? Give feedback.
All reactions