aleidk/master-wiki
1
0
Fork 0
Code Issues 11 Pull requests Projects Releases Packages Wiki Activity Actions

add void repo files

Browse source
This commit is contained in:
Alexander Navarro 2024-11-13 21:29:52 -03:00
parent 80ef6e92c4
commit 11895a94c4
148 changed files with 15344 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

27
void/Readwise/Sharing Code Between Projects Lessons Learned in the Trenches.md Normal file
View file

@ -0,0 +1,27 @@
# Sharing Code Between Projects: Lessons Learned in the Trenches
![rw-book-cover](https://archive.smashing.media/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/adc3be2f-343a-4bee-8ee8-2cec63967354/01-sharing-code-between-projects-800w.png)
## Metadata
- Author: [[Smashing Magazine]]
- Full Title: Sharing Code Between Projects: Lessons Learned in the Trenches
- Category: #articles
- URL: https://www.smashingmagazine.com/2018/04/sharing-code-between-projects/
- Archive: https://web-archive.alecodes.page/bookmarks?bf=1&search=&title=Sharing%20Code%20Between%20Projects%3A%20Lessons%20Learned%20in%20the%20Trenches
> [!tldr]
> Jonathan Saring discusses the challenges of sharing code between projects and the lessons learned by his team. They found that code duplication was widespread and sought a better way to share components without the complexities of multiple repositories or libraries. This led to the creation of Bit, a tool that simplifies code sharing and collaboration across projects.
## Highlights
Trying to publish a few files from our project to NPM forced us to split our repository and create new ones just to share this code. When dealing with hundreds of components, **this meant having to maintain and make changes across hundreds of repositories**. [View Highlight](https://read.readwise.io/read/01j7c7r70prgze7nhnwf9mrvyb))
Even then, we had now a simple way to organize these packages and make them easily [discoverable](https://medium.com/@Rich_Harris/small-modules-it-s-not-quite-that-simple-3ca532d65de4#.88d5anyhv) to our entire team. Another major problem was the coupling between the packages and the owners of their origin repositories, which made it nearly impossible for other people to quickly make updates to the packages while working on their own projects. [View Highlight](https://read.readwise.io/read/01j7c7snv6bz7w24x6v99zar37))
Choosing this option meant we would still have to effectively keep multiple packages with multiple `package.json` files, multiple build and test environments and a complicated dependency tree to handle between them. Updating these packages must also go through the main repository, still making it hard to modify these package from other projects when working with a few separate monorepos. [View Highlight](https://read.readwise.io/read/01j7c7tyqzf8z4ns8sr35gstvb))
This option was quickly dropped, too. In a lot of way, it resembles using a CD-ROMs instead of an iTunes playlist. First, it made no sense to force an entire library of React components and an entire utility library and so on on each of our projects.
Secondly, every project using it would be tightly coupled to the development of this library, making it impossible to adjust its components for each project. This becomes most painful when sharing common Node.js code between our microservices, which would now be coupled to the library.
Thirdly, discoverability within the library is bound to be poor and would involve a lot of work with its documentation and usage in different edge cases. [View Highlight](https://read.readwise.io/read/01j7c7x4br1vpa6peckn8f04x1))
You there. You're thinking about using a Git submodule. DON'T. Just don't. It's not worth it, ever.
— Jeremy Kahn (@jeremyckahn) [December 16, 2012](https://twitter.com/jeremyckahn/status/280406794583539712?ref_src=twsrc%5Etfw) [View Highlight](https://read.readwise.io/read/01j7c7zhs027w5jac3mg71v905))