[node-workspace
plugin] making the difference between npm workspaces and sub-packages in a monorepo
#2432
Labels
priority: p3
Desirable enhancement or fix. May not be included in next release.
type: feature request
‘Nice-to-have’ improvement, new feature or different behavior or design.
Is your feature request related to a problem? Please describe.
I'm encountering a problem with the
node-workspace
plugin in a monorepo setup. Let's assume the following monorepo containing 3 packages:lib
: react library of componentsapp
: nextJS application importinglib
extension
: another nextJS application using the published npm oflib
, not the one available locallyIn this context,
lib
andapp
are defined as npm workspaces and share a commonpackage-lock.json
at the root of the monorepo. Theextension
package is managed separately, with its ownpackage-lock.json
.When using
release-please
with this configuration:The tool updates the versions of all packages simultaneously (role of
linked-versions
, including bumping the version oflib
within both the rootpackage-lock.json
andextension/package-lock.json
(role ofnode-workspace
relying onpackages
). This leads to inconsistencies, as theextension
package'spackage-lock.json
may reference a version oflib
that hasn't been published yet, resulting in discrepancies between theversion
andresolved
fields:Describe the solution you'd like
To prevent such inconsistencies, it would be beneficial if the
node-workspace
plugin could selectively update package versions. Specifically, for packages not part of the npm workspace (likeextension
), the plugin should update their version without altering dependencies related to the monorepo.Implementing an option to define which packages should be managed as npm workspaces within the
node-workspace
plugin would allow for selective version updates. For example:In this configuration, the
node-workspace
plugin would manage version updates forroot
,lib
, andapp
, while excludingextension
from workspace dependency updates. Nevertheless, the versions of all the packages would remain linked together.Describe alternatives you've considered
An alternative approach involved excluding
extension
from the packages configuration and using theextra-files
option to manually update its version:However, this method does not fully resolve the issue, as the
extension
package's version remains unlinked from the other packages, leading to potential version mismatches.Additional context
Why isn't
extension
part of the npm workspaces?The
extension
package is designed to assist a community in developing their own applications, extending beyond the capabilities ofapp
andlib
. Including it in the npm workspaces could lead to unintended dependencies and versioning issues.How do you update the
lib
dependency withinextension
?The
lib
dependency in extension can be managed byDependabot
, treating it as an external dependency. This approach ensures that extension always uses the latest published version of lib, similar to how it would function for a communities developing their own extensions.Thanks!
The text was updated successfully, but these errors were encountered: