New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why monorepo? #25748
Comments
|
The easiest way to do that is to use the TypeSearch. You will find out whether the types are in the registry, and if they are, the link in the npm description will point exactly to their subfolder. |
Non-monorepo is a nonstarter. Frequently, contributors modifying something in one |
I'm not familiar with writing But isn't it what semver is for? I expect it to work the same: dependency graph where you have eg. package Probably on top of that you have Or if it is possible, just allow implementers to publish directly under |
https://github.com/npm/npm also 2k issues. The best solution is the author maintaining definition, which has always been encouraged. |
@FranklinYu Number of issues is not what's under question. Taking into account this repo aggregates >4k typings, that huge number of issues is ok. Real question is: what problem |
Unfortunately, semver does not work well for typings packages. The For example, right now if you install |
@aj-r Ok, What does that have to do with original question: monorepo vs separate repos? |
Sorry, I should have been clear - I was addressing one of your previous comments:
|
What problem is splitting up DT into 4,000 separate GitHub repos going to solve? Every day a TypeScript team member manages the PR backlog, merging or reviewing several dozen PRs. A bot keeps tabs on the huge volume of PRs we get. We run repo-wide lint rules that catch common errors, and we turn on new lint rules regularly as we think of ones that would help. We find and fix definitions with things broken by future compiler versions. Splitting this out into thousands of subrepos makes all of that harder, and makes nothing else easier. So why would we do it? |
|
You're approaching this from the mindset that typings are actually owned by anyone. The reality is that the great majority of files in this repo were written once by someone who ran dts-gen and checked it in with a few fix-ups, then got touched up once a year by three other people. There is not a strong ownership model here, nor does there need to be. What happens when the ad-hoc self-declared "owner" of one of these repos decides to stop maintaining it? This happens all the time. How do we keep track of which repo is the current "best"? What happens if they start merging changes that result in things we can't publish on NPM? This also just does make life worse for people who want to submit fixes. Last year we added a type parameter to the React definition file that required downstream changes in several hundred files. Does anyone want to clone several hundred repos (oh, and which repos?) to make a wide-spanning change, then manage several hundred concurrent pull requests? There isn't even tooling for this anywhere. |
We literally tried this and it didn't work. DT was solely community driven and it resulted in a pull request backlog hundreds deep. Since then the average time to merge a PR has fallen from 2 weeks to 4 days (which is an intentional minimum so people have time to weigh in on changes), even though PR volume has gone from ~200/month to ~1,000/month. |
Ok, I think I have the answer on my original question "Why monorepo?": I still think that the model where TypeScript team takes such a major role in maintaining thousands of packages mostly by itself is a bit weird. Especially in the modular, community driven npm world. But if this model works for you. Then ok 😃 |
@art-in I don't believe the intention is to manage all types from this one repo, it is to manage types that aren't provided by the packages themselves. If a package wants to publish types for its package, it can do so right in the package. DefinitelyTyped is just a place where types can be aggregated without needing consent from the original package maintainer. |
I want to see .d.ts for
@types/X
package without cloning repo.But when I open types folder on github I see following error, and
X
folder is not listed.Sorry, we had to truncate this directory to 1,000 files. 3,413 entries were omitted from the list.
I want to see what issues already filed for
@types/X
and file new one.But when I open issues tab I see >2k entries for all the packages... I wonder how contributors even find issues filed for their definitions (or they don't?).
Why typings do not live in separate repos? Isn't this monorepo a total mess?
The text was updated successfully, but these errors were encountered: