4 ms·

Ime the support for workspaces/monorepos is often mixed. It takes more time to setup correctly, in comparison to having multiple repositories, and can sometime

by c0balt 2y ago

Ime the support for workspaces/monorepos is often mixed. It takes more time to setup correctly, in comparison to having multiple repositories, and can sometime slead to weird errors. In the NPM/Yarn world at least this was something we encountered recently. Python has matured here but can also sometimes have weird edge cases.

n00bskoolbus 2y ago
Not sure that multiple repos is a good comparison for local development at least. If you go the polyrepo route with NPM/Yarn (for example) you'll probably still be using linking or a filepath in the package.json dependencies. I don't think monorepo vs polyrepo eliminates the problems that come with this like making sure changes from a library are hot reloaded into another which is something that still seems to require lots of configuration.
scubbo 2y ago
> Ime the support for workspaces/monorepos is often mixed. It takes more time to setup correctly, in comparison to having multiple repositories Ah - this highlights that I have misunderstood something, then - because, to my mind, a workspace _is_ multiple repositories, which are siblings within a directory. Something like: . └── Root of the workspace/ ├── repository-1/ │ ├── src │ ├── tst │ ├── Dockerfile │ └── ... └── repository-2/ ├── src ├── tst └── ... Configured such that, if the code in repository-1 depended on the library built from repository-2, repository-1 would "see" the live-updated version immediately. But it sounds like you're saying that that's not the case, and that your mental model of a workspace _is_ just a single repo? Am I understanding that right?
- c0balt 2y ago
  Yes, indeed. A workspace (https://docs.npmjs.com/cli/v7/using-npm/workspaces?v=true https://docs.npmjs.com/cli/v7/using-npm/workspaces?v=true) as used with a monorepo, where one gut repository contains multiple packages.
  - scubbo 2y ago
    Hmm - it looks like a(n NPM) workspace _can_ be used inside a monorepo, but that there's nothing _requiring_ it to be so used. Why can't the packages inside the workspace be separate repos?

by c0balt 2y ago

n00bskoolbus 2y ago

Not sure that multiple repos is a good comparison for local development at least. If you go the polyrepo route with NPM/Yarn (for example) you'll probably still be using linking or a filepath in the package.json dependencies. I don't think monorepo vs polyrepo eliminates the problems that come with this like making sure changes from a library are hot reloaded into another which is something that still seems to require lots of configuration.

scubbo 2y ago

> Ime the support for workspaces/monorepos is often mixed. It takes more time to setup correctly, in comparison to having multiple repositories Ah - this highlights that I have misunderstood something, then - because, to my mind, a workspace _is_ multiple repositories, which are siblings within a directory. Something like: . └── Root of the workspace/ ├── repository-1/ │ ├── src │ ├── tst │ ├── Dockerfile │ └── ... └── repository-2/ ├── src ├── tst └── ... Configured such that, if the code in repository-1 depended on the library built from repository-2, repository-1 would "see" the live-updated version immediately. But it sounds like you're saying that that's not the case, and that your mental model of a workspace _is_ just a single repo? Am I understanding that right?

c0balt 2y ago
Yes, indeed. A workspace (https://docs.npmjs.com/cli/v7/using-npm/workspaces?v=true https://docs.npmjs.com/cli/v7/using-npm/workspaces?v=true) as used with a monorepo, where one gut repository contains multiple packages.
- scubbo 2y ago
  Hmm - it looks like a(n NPM) workspace _can_ be used inside a monorepo, but that there's nothing _requiring_ it to be so used. Why can't the packages inside the workspace be separate repos?