Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add policy on using caret (^) or tilde (~) with dependencies #290

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
87 changes: 87 additions & 0 deletions docs/adr/002-policy-on-using-caret-with-dependencies.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,87 @@
# ADR 002: Policy on Using Caret (`^`) or tilde (`~`) with Dependencies in `package.json`

## Status
Proposed

## Submitters
- Ulises Gascón (@UlisesGascon)

## Decision Owners
- Express TC (@expressjs/express-tc)

## Context
Historically, the Express project has avoided using the caret (`^`) in the `package.json` files for its own dependencies. This decision aims to review whether this practice should continue or if adjustments are needed.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Historically, the Express project has avoided using the caret (`^`) in the `package.json` files for its own dependencies. This decision aims to review whether this practice should continue or if adjustments are needed.
Historically, the Express project has avoided using the caret (`^`) in the `package.json` files for its own dependencies. This proposal aims to review whether this practice should continue or if adjustments are needed.


**Why do we need this decision?**
Clarifying the policy on using caret (`^`) helps to ensure consistency across the Express ecosystem, reduce unnecessary maintenance, and prevent unexpected dependency updates. It also addresses concerns about the balance between keeping dependencies up-to-date and avoiding regressions.

**What problem does it solve or avoid?**
This decision aims to avoid unexpected updates and regressions from external dependencies while reducing the maintenance burden of frequently updating pinned dependencies.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This decision aims to avoid unexpected updates and regressions from external dependencies while reducing the maintenance burden of frequently updating pinned dependencies.
This decision aims to reduce the maintenance burden of frequently updating pinned dependencies.


**Are there any existing issues/discussions/pull requests related to this?**
- [Discussion: Using caret (^) with our own dependencies #279](https://github.com/expressjs/discussions/issues/279)
- [expressjs/express#6017 (comment)](https://github.com/expressjs/express/issues/6017)

## Decision
We will adopt a policy where the caret (`^`) symbol is used for dependencies owned within the Express ecosystem (e.g., `body-parser` for Express), but continue to avoid using it for third-party dependencies that we do not maintain.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not also for third party deps? most maintainers don't backport fixes to previous minors.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, we should always use ^ and use dependencies/authors we trust, no need to fight the ecosystem.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed!

Suggested change
We will adopt a policy where the caret (`^`) symbol is used for dependencies owned within the Express ecosystem (e.g., `body-parser` for Express), but continue to avoid using it for third-party dependencies that we do not maintain.
We will adopt a policy where the caret (`^`) symbol is used for dependencies all dependencies.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
We will adopt a policy where the caret (`^`) symbol is used for dependencies owned within the Express ecosystem (e.g., `body-parser` for Express), but continue to avoid using it for third-party dependencies that we do not maintain.
We will adopt a policy where the caret (`^`) symbol is used for all dependencies.


**What will be done?**
- Update the `package.json` files to use `^` for our own dependencies.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Update the `package.json` files to use `^` for our own dependencies.
- Update the `package.json` files to use `^` for all dependencies (both prod and dev).

- Continue using fixed versions (no caret or tilde) for external dependencies to minimize risks of unintended updates.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Continue using fixed versions (no caret or tilde) for external dependencies to minimize risks of unintended updates.


**Note on `^` vs. `~`:**
- `^` allows updates to the most recent minor or patch version, offering greater flexibility and reducing the need for frequent manual updates. For example, `^1.2.3` will accept updates to `1.3.0`, `1.4.0`, but not `2.0.0`.
- `~` is more conservative, only allowing updates to patch versions. For example, `~1.2.3` will accept updates to `1.2.4`, `1.2.5`, but not `1.3.0`.
- For our own dependencies that adhere strictly to semver, `^` is preferred over `~`, while for third-party libraries, a stricter versioning strategy is maintained to prevent unexpected regressions.

**What will not be done?**
- We will not use `^` or `~` for external dependencies that are not maintained by the Express organization, as they could introduce unexpected changes.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure there's any reason to use ~ either, I think we would have used it instead of ^ due to supported NPM versions.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's indeed the only reason express used ~, because v4 came out at a time when not every npm version supported ^.

- We won't force to use `^` or `~` for own dependencies if there is a reason to use a fix version and it is properly documented.

## Rationale

**Alternatives Considered:**
- **Alternative 1:** Use `^` for all dependencies, including third-party libraries.
- **Reason for rejection:** This could increase the risk of unintended regressions and security issues from third-party updates.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

imo this risk is lower than the risk of dependency vulnerability/regression fixes from not being available to downstream users.

- **Alternative 2:** Continue pinning all dependencies, including internal ones, to specific versions.
- **Reason for rejection:** This approach requires frequent updates and increases the maintenance burden, as each minor or patch update requires a new release.

**Pros and Cons**:

**Pros**:
- Reduces the number of PRs for updating our own dependencies.
- Allows for quicker adoption of minor and patch updates within the Express ecosystem.
- Users are still protected by lockfiles, mitigating the risk of regressions.

**Cons**:
- There is still a risk of minor regressions from updates, even within internally managed dependencies.
- Requires discipline in maintaining lockfiles to ensure stability for end users.

**Why is this decision the best option?**
This decision strikes a balance between reducing maintenance effort and managing risk. It allows Express to leverage the benefits of semver for our own dependencies while maintaining control over external libraries that could introduce breaking changes.

## Consequences

**Positive Impact**:
- Fewer manual updates required for internally managed dependencies.
- Users benefit from improvements and fixes in internal packages more quickly.

**Negative Impact**:
- Potential risk of regressions if an internal dependency introduces a breaking change in a minor update.
- Users relying on strict version control may need to adjust their expectations when using our own dependencies.

**Mitigations**:
- Strong test coverage and CI checks will help catch potential issues early.
- Clear communication in documentation and release notes to inform users of the updated dependency policy.
- Ensure that we are following strict semver when releasing our own libraries.

## Implementation

- **Phase 1**: Update `package.json` files across all packages to apply `^` for our own dependencies.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- **Phase 1**: Update `package.json` files across all packages to apply `^` for our own dependencies.
- **Phase 1**: Update `package.json` files across all packages to apply `^` for all dependencies.

- **Phase 2**: Review and adjust documentation to include the new policy on dependency versioning.

## References
- [NPM semver documentation](https://docs.npmjs.com/cli/v6/using-npm/semver)

## Changelog
- **[2024-10-22]**: @UlisesGascon - Initial draft of ADR for using caret (`^`) or tilde (`~`) with our own dependencies.