Support yarn workspaces, lerna packages
dylang opened this issue · comments
Yarn natively supports monoropos through a setting called workspaces.
When using npm, a project called lerna has a packages setting.
- https://yarnpkg.com/lang/en/docs/workspaces/
- https://yarnpkg.com/blog/2017/08/02/introducing-workspaces/
- https://github.com/lerna/lerna#lernajson
The workspaces config in the root package.json, or packages in lerna.json lists glob patterns for all the workspaces.
If typesync is run in a project with workspaces, it would be great if it ran across all of the workspaces simultaneously.
A workaround is to run yarn lerna exec typesync to execute typesync in every package directory, but it's much slower because it's spawning a copy of typesync for each package.json. My repo has 40+ packages and lots of duplication between them.
Interesting.
I am sure the slowness is caused by having to download and unzip the JSON multiple times. I wonder if I cache the download for like a few minutes, it should probably be faster instead of having to cater to every possible monorepo tool.
What do you think, would that be enough? If anything, I should probably be doing this already. I wonder if there is a way to check when a new version of the JSON blob is available.
It's both simultaneously overly verbose and not helpful when running through lerna exec:
Here's a small snippet, this goes on for pages.
» TypeSync v0.3.1
✔ 1 typings added:
+ @types/is-ci
✨ Go ahead and run npm install or yarn to install the packages that were added.
» TypeSync v0.3.1
» TypeSync v0.3.1
» TypeSync v0.3.1
⠋ Syncing type definitions in package.json...» TypeSync v0.3.1
✔ No new typings added, looks like you're all synced up!
✔ No new typings added, looks like you're all synced up!
✔ 1 typings added:
+ @types/is-ci
✨ Go ahead and run npm install or yarn to install the packages that were added.
⠴ Syncing type definitions in package.json...» TypeSync v0.3.1
⠋ Syncing type definitions in package.json...» TypeSync v0.3.1
⠙ Syncing type definitions in package.json...» TypeSync v0.3.1
✔ No new typings added, looks like you're all synced up!
✔ 2 typings added:
+ @types/git-branch
+ @types/is-ci
✨ Go ahead and run npm install or yarn to install the packages that were added.
✔ No new typings added, looks like you're all synced up!
✔ No new typings added, looks like you're all synced up!
» TypeSync v0.3.1
» TypeSync v0.3.1
✔ No new typings added, looks like you're all synced up!
✔ No new typings added, looks like you're all synced up!
» TypeSync v0.3.1
» TypeSync v0.3.1
» TypeSync v0.3.1
⠋ Syncing type definitions in package.json...⠋ Syncing type definitions in package.json...» TypeSync v0.3.1
✔ No new typings added, looks like you're all synced up!
✔ No new typings added, looks like you're all synced up!
✔ No new typings added, looks like you're all synced up!
✔ No new typings added, looks like you're all synced up!
» TypeSync v0.3.1
⠋ Syncing type definitions in package.json...» TypeSync v0.3.1
⠋ Syncing type definitions in package.json...» TypeSync v0.3.1
⠋ Syncing type definitions in package.json...» TypeSync v0.3.1
✔ No new typings added, looks like you're all synced up!
✔ 1 typings added:
+ @types/is-ci
...cut...
All I'm worried about is coupling to lerna/yarn workspaces format. But I guess there's benefit to it.
I guess the globs represent folders that contain package json's, so my initial approach would be to filter out files from the glob results and attempt loading package.json's within them.
It's definitely over verbose, how would you envision the output in this case?
@dylang what do you think of this?
Implemented as of v0.4.0.
Amazing job, works great!
This is pretty great, but with lerna at least most people would put all the type defs in the root devDependencies rather than spread across the packages. 🤷♂️
I use neither, so I don't know what people do and don't do. 🤷♂️ Whatever the behavior needs to be, it needs to be consistent across both.