Decoupled App Dependencies #22641
Replies: 24 comments 3 replies
-
|
Similar discussion:
But having to use a different package manager doesn't sound like a desirable solution
According to the docs you may also look into using the package based instead of integrated repo.
Seems like the docs don't want people to maintain multiple projects with varying dependencies with nx |
Beta Was this translation helpful? Give feedback.
-
|
I have thought about it how I would go about permitting projects with completely decoupled dependencies. Anyhow, I know this is a big ask. For now, I will continue using Nx as it is got some nice things going for it, but if I see some new workspace framework one up Nx by allowing us to maintain completely decoupled projects I'd have to strongly reconsider where to go. Honestly, I am just looking for a core team member to say whether this is something worth pursuing, I don't mind doing the work and raising a PR as long I have some degree of confidence it'll be accepted. |
Beta Was this translation helpful? Give feedback.
-
|
Oh boy, I just read this https://nx.dev/more-concepts/dependency-management. This whole thing seems to advocate for Single Version Policy. On paper it sounds nice, in reality coupled projects through dependencies is just that coupling, not suitable for agile development. I would like to challenge this. I've worked on large monorepos managed by different teams, with different scopes, time-zones, capacity, and timelines and we've gotten burned by having this single dependency. Where teams could upgrade because it would break everyone else's project. Unless Nx has development some amazing way up upgrade all coupled projects simultaneously with no issues. Is it a matter of "its too complicated" to come up with this feature? If you break down what is required to get this done is.
|
Beta Was this translation helpful? Give feedback.
-
|
In general, we do recommend a single version policy, but if you prefer to manage your own versions separately, then you should use the package based repo approach or Lerna. It looks like you've found all the relevant documentation. If you want to create your own plugin to help other people that want to follow your same approach, that's great. You can submit it to be listed along with the other community plugins. |
Beta Was this translation helpful? Give feedback.
-
|
Okay, so I will create and submit another community plugin. Initial scope is:
Does anyone know if nx migrate/update will recursively update nested' project dependencies? (E.g. libs/packages). If so, is there a way to flag a project other than (E.g. libs/packages) to also receive dependency updates when this process occurs, or would you rather have it taken care of by the plugin as well? I will leave this discussion open in case anyone else has anything to add. |
Beta Was this translation helpful? Give feedback.
-
|
I have still plans to look into this by the way. |
Beta Was this translation helpful? Give feedback.
-
|
@isaacplmann, thanks for taking the time to get involved in the discussion. Looking at googles single-version policy, and other tooling like Bit and Rush, they all seem to allow exceptions or variants, which allows big teams working in large code bases to migrate over time and gives teams greater autonomy. Without this, the alternative is to do everything at once, either centrally or via coordinating many teams. This becomes increasingly difficult as code and teams grow. Apart from allowing independent projects from a package management point of view, are there any other differences (pros vs cons) when selecting between "Package-Based Repos" and "Integrated Repos"? Creating a plugin sounds like an OK workaround, but can NX be configured in Integrated Repo mode to allow these exceptions? It feels like it would be nice for say 99% of the repo to be in integrated mode and for only those exceptions to have to be specified, perhaps with a package.json, but this mix doesn't sound possible atm (even with a custom executor/generator)? |
Beta Was this translation helpful? Give feedback.
-
|
@peter-mouland Off the top of my head, here are the problem points you'll need to watch out for:
|
Beta Was this translation helpful? Give feedback.
-
|
ah that's interesting, so to confirm we could use integrated repos and remove package.json for most of our projects, then just add the package.json back into those that require a different version? if so, that sounds like a good solution. As far as multiple versions of the same dep goes, my current thinking is to prevent 'libs' from specifying exact dep versions, or perhaps use peerDeps to ensure they stay flexible. 'apps' (in our case a login page, or dashboard etc) would then select the version to be used for that project. This way different apps can use what they need and allows a bit of flexibility - whilst preventing different versions of deps within the same distributable. thanks for the insight |
Beta Was this translation helpful? Give feedback.
-
The situation I've found is even worse. |
Beta Was this translation helpful? Give feedback.
-
|
@AndrewRedican No pressure :) |
Beta Was this translation helpful? Give feedback.
-
@benzsuankularb You are describing precisely what I've seen happen on other mono repo setups.
@benzsuankularb In short, I haven't started any work on this. I've been awfully busy, between my day job, side hustle, and family. I've only released the gas pedal on the side hustle, so I may have some time now. I used NX on a daily basis, so I am committed to solving this problem. I will be counting on people to give feedback and do some beta testing. |
Beta Was this translation helpful? Give feedback.
-
|
This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs. |
Beta Was this translation helpful? Give feedback.
-
|
Not stale |
Beta Was this translation helpful? Give feedback.
-
|
@AndrewRedican |
Beta Was this translation helpful? Give feedback.
-
|
What did you do to have individual node_modules per package? |
Beta Was this translation helpful? Give feedback.
-
|
I do nothing. Just switch to PNPM. |
Beta Was this translation helpful? Give feedback.
-
|
This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs. |
Beta Was this translation helpful? Give feedback.
-
|
Any updates on this? |
Beta Was this translation helpful? Give feedback.
-
|
This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs. |
Beta Was this translation helpful? Give feedback.
-
|
Bump to remove stale label |
Beta Was this translation helpful? Give feedback.
-
|
This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs. |
Beta Was this translation helpful? Give feedback.
-
|
Bump to remove stale label |
Beta Was this translation helpful? Give feedback.
-
|
This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs. |
Beta Was this translation helpful? Give feedback.
-
|
Bump to remove stale label |
Beta Was this translation helpful? Give feedback.
-
|
It's absolutely true that the flexibility to support having multiple sets of dependencies alleviates a lot of the friction with initially moving into a monorepo. We plan to fully support importing projects along with their dependencies into the workspace. Stay tuned. We do not intend to change the default code generation to not use the single version policy. We believe there is a very good reason to recommend it. We can look into what may need to change to better support managing different sets of dependencies. If there are specific issues that you come across where Nx does not respect packages managed in sub directories, we will look into fixing them. I'll move this over to a discussion on the broader topic. Please open separate specific issues you run into. |
Beta Was this translation helpful? Give feedback.
-
|
Just to deliver on the
My scenario is the usage of opentelemetry auto-instrumentation. It won't get ever imported in the code but instead resides in my Dockerfile with |
Beta Was this translation helpful? Give feedback.
-
Description
I would like to keep dependencies for each app project completely separate to each other, and not share dependencies.
Motivation
One of the pain points with some monorepos setups (Angular) is that projects get coupled together through dependencies. The reason I started using Nx was precisely the fact that every project (or so I thought) in the workspace was completely decoupled, which seems to only apply to libraries/packages weirdly.
Having apps share dependencies make no sense. If different teams own different projects, and one of them were to upgrade the version with a breaking change it'll force an upgrade on all projects, this would not scale for a much larger organization.
Suggested Implementation
I would've expected every generated app of any kind, have its own package.json created by default.
Alternate Implementations
Otherwise an option should be clearly documented to opt in or out of share dependencies.
Beta Was this translation helpful? Give feedback.
All reactions