search

repeaterjs / repeater

The missing constructor for creating safe async iterators
https://repeater.js.org
MIT License
459 stars 12 forks source link

Move utility packages to their own repositories #34

Open brainkim opened 5 years ago

brainkim commented 5 years ago

The yarn monorepo format is pain to deal with, is difficult to integrate with github/javascript/typescript tools and hasn’t really been useful in any meaningful way. I’ve twice accidentally published dependent packages without updating internal dependencies because packages are symlinked together. I have a github org with lots of space so why not use it to its full potential, and allow for better discoverability.

akaRem commented 4 years ago

Why not put everything in one package and allow partial import like in lodash. So it would be possible to reduce size of bundled app. You can put experimental stuff in experimental subfolder. There are ~6..15 different exported items spread across 4 packages. I'd say it's overkill. Imagine if lodash would put every 5..10 functions in different package.

brainkim commented 4 years ago

@akaRem I’m more inclined to keep them in separate packages, because the repeater API is more or less stable. In its current form, I like to think the repeater API is pretty much the most ideal API for a callback-driven async generator-compatible class and further changes will mainly be bug fixes/performance improvements.

danielweck commented 2 years ago

Turborepo should ease the pain: https://github.com/vercel/turborepo