3 ms·
> Creating a library also harms the development experience, because changes to the code no longer take effect immediately, as we need to build a library every t
by scubbo 2y ago
> Creating a library also harms the development experience, because changes to the code no longer take effect immediately, as we need to build a library every time we make a change.[0]
I see this criticism of libraries from monolith fans a lot, and it confuses me. That would be true anyway - you cannot use code until you've built it (unless it's in a language which is interpreted/unbuilt/uncompiled etc.). This would be true if the code lived in a separate repo or in the same monorepo.
I suspect what they really mean is "you can't consume a new version of a library until that new version has been built _and pushed to a package registry_ from which it can then be referenced", which is just false in any language I have any familiarity with - Yarn Workspaces[1] allows the "live" use of Typescript libraries in a local development environment, Python has plenty of solutions[2], even the minimalist GoLang has Workspaces[3]. What am I missing? Is there some language which lacks this Workspaces support for "depending on local versions of dependencies" that is driving all this monolith-fever?
[0] https://polylith.gitbook.io/polylith/introduction/sharing-code#creating-a-library https://polylith.gitbook.io/polylith/introduction/sharing-co...
[1] https://yarnpkg.com/features/workspaces https://yarnpkg.com/features/workspaces
[2] https://stackoverflow.com/questions/1112618/import-python-package-from-local-directory-into-interpreter https://stackoverflow.com/questions/1112618/import-python-pa...
[3] https://go.dev/doc/tutorial/workspaces https://go.dev/doc/tutorial/workspaces
- c0balt 2y agoIme 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 agoNot 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 agoYes, 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 agoHmm - 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?
- d0mine 2y agoManually hacking `sys.path` somewhere in the guts of your project is a path to madness. During development, `pip install -e .` can be used to get installation from the local directory (changes are available immediately).