fix: Loosen dependency requirements

[wojtekmaj]

Using exact dependency versions can be harmful, as it blocks downstream bug fixes, security patches, and new features. It can also increase the risk of duplicate packages in node_modules, leading to subtle, hard-to-debug issues.

This PR changes all user-facing dependencies from x.y.z to ^x.y.z, allowing end users to automatically benefit from compatible updates as they are released.

Summary by CodeRabbit

• Chores
  • Updated dependency version ranges to allow automatic minor and patch updates for several packages (debug, jsonwebtoken, node-forge, verror).
  • No changes to runtime logic or public APIs; review effort assessed as low/medium.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[parse-github-assistant]

🚀 Thanks for opening this pull request!

[coderabbitai]

📝 Walkthrough

Walkthrough

The package.json dependency entries for debug, jsonwebtoken, node-forge, and verror were changed from exact version pins to caret (^) ranges. No source files, runtime logic, exports, or control flow were modified.

Changes

Cohort / File(s)	Change Summary
Dependency Version Ranges package.json	Changed dependency versions from exact pins to caret (^) ranges for debug, jsonwebtoken, node-forge, and verror.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

• Review focus: confirm caret ranges are intentional and acceptable for CI/release policies; run dependency install and tests to ensure no unexpected breakage.

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'fix: Loosen dependency requirements' directly and concisely describes the main change—converting exact version pins to caret ranges in package.json dependencies.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b9fd03c and f6416b6.

⛔ Files ignored due to path filters (1)

• package-lock.json is excluded by !**/package-lock.json

📒 Files selected for processing (1)

• package.json (1 hunks)

🔇 Additional comments (1)

package.json (1)

21-24: Pragmatic balance between determinism and downstream flexibility.

The change from exact version pins to caret ranges aligns with semver best practices and mirrors the existing pattern in devDependencies (lines 27-44). This strikes a reasonable balance:

• CI reproducibility preserved: package-lock.json continues to lock exact versions for deterministic builds.
• Downstream benefits: End users can receive security patches and bugfixes automatically without duplication or manual updates.
• Risk mitigation: Caret ranges still prevent accidental major-version breakages.

The Snyk scan showing 0 issues is a good signal. However, success depends on these packages maintaining strict semver compliance.

Ensure comprehensive test coverage. Given that regressions from upstream minor/patch updates can now occur, please verify that the existing test suite (mocha, nyc coverage) is comprehensive enough to catch breaking changes within minor versions. Run the test suite and confirm coverage thresholds are maintained.

Verify lockfile strategy remains intact. Confirm that package-lock.json is committed to version control and that CI explicitly uses npm ci (or equivalent) to install locked versions, preserving reproducibility for your builds while letting downstream consumers benefit from flexibility via npm install.

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
4. 📊 Contributor Summary — Include a Markdown table showing contributions:
   | Contributor | Lines Added | Lines Removed | Files Changed |
5. ✔️ Additional Notes — Add any extra reviewer context.
   Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[parseplatformorg]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.84%. Comparing base (4eb180c) to head (f6416b6).

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #182   +/-   ##
=======================================
  Coverage   95.84%   95.84%           
=======================================
  Files          23       23           
  Lines         842      842           
=======================================
  Hits          807      807           
  Misses         35       35           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mtrezza]

We generally use exact version references to allow for deterministic testing. The solution is to continuously update the dependencies.

[parse-github-assistant]

The label type:meta cannot be used here.

[wojtekmaj]

Seems like something that a lockfile could help with.

[mtrezza]

There is a package-lock file. If you look at merged PRs, you can see that they are opened automatically. If there are dependencies that are not updated, then it may be a bot issue we'd need to look into.

[wojtekmaj]

Therefore you already have everything to make your tests deterministic and there's no point in carrying on your shoulders the burden of responsibility for updating consumer's dependencies! :)

[mtrezza]

There are several reasons why it is the way it is. One being that package-lock can get corrupted and may need to be recreated, in which case the versions would be all over the place if we didn't fix them in the package.json as well. But this is beside your original point: dependencies should be automatically upgraded by dependabot, so if a dependency is not upgraded, please let me know which one it is.

[benmccann]

The lock file is stored in git. There is no way that it can become corrupted that we can't just revert to a working version. And even if we did need to start over for some reason, we could do so while keeping the versions the same - it's a bit complicated to do so, but straightforward once you understand how.

If every project were to pin dependencies you would end up with a dozen copies of popular dependencies because it prevents them from being deduplicated when slightly different versions are used.

[mtrezza]

First, thanks everyone for the thoughtful discussion. Over the years we’ve run into just about every issue imaginable around package-lock.json corruption and edge cases. That’s one reason why we keep the lockfile committed and rely on locked dependency versions for reproducible builds. It would be inconsistent to say “we have a lockfile to lock versions” while also expecting package.json to remain version-unlocked. Our intent is to lock versions. As a final note on the topic, we discourage changing dependency versions as our CI tests only run against the pinned versions. If you’d like to try different versions and run your own CI, please feel free to fork the repo, remove the lockfile, and rebuild, considering the risks.

[wojtekmaj]

please feel free to fork the repo, remove the lockfile, and rebuild, considering the risks.

Just so we're in the clear: no one's advocating against the presence of the lockfile, which definitely should stay!

We're advocating against pinning dependency versions for end consumers, which pushes your determinism problem onto all consumers and often causes duplicate trees and missed/delayed security/bugfix releases.

[mtrezza]

It’s a trade-off. We prefer pinning direct dependencies because it guarantees our CI runs against the exact versions we ship. In the wild, upstreams occasionally don’t follow semver, and unpinned ranges can let those breakages reach developers before we can catch them. With pins, our CI identifies regressions without passing risk downstream. Sure there's the downside of duplicate installs, but that’s mostly bloat rather than a functional issue, and developers who want a single version can use npm overrides. In our view, pinning defaults to stability while still giving a conscious escape hatch.
We can try to introduce ranges selectively where we find duplication issues. Let me discuss this and get back; we'll keep the issue open meanwhile.

[parse-github-assistant]

I will reformat the title to use the proper commit message syntax.

[wojtekmaj]

@mtrezza, FYI, since this PR has not been merged, @parse/node-apn is currently a subject to GHSA-65ch-62r8-g69g, GHSA-554w-wpv2-vw27, and GHSA-5gfm-wpxj-wjgq.

I have rebased the PR to fix conflicts and bumped node-forge while at it.

[mtrezza]

@wojtekmaj How is the node-forge fix related to introducing version ranges? Isn't a node-forge dependency bump all that's needed for the fix?

[wojtekmaj]

It is, but it requires an explicit action on your side - this time and, crucially, every time it happens ever again. At the moment, @parse/node-apn package.json explicitly disallows a security patch by forcing its consumers to use an exact, vulnerable node-forge version. Dependabot fails on hundreds of repositories on what could be a fully automated fix.

[mtrezza]

@wojtekmaj If a security vulnerability was only fixed in the next major version of a dependency, then your suggested caret range wouldn't be enough. To follow through with your argument we'd have to set all dependency versions to wildcard range, which means no robustness.

This confirms that the solution is an explicit dependency upgrade. We'll therefore keep the exact versions in package.json, and also for the aforementioned reasons.

To fix the node-forge vulnerability you could open a PR which upgrades the dependency. I will investigate why the PR hasn't been opened automatically, which should have happened.

[wojtekmaj]

If a security vulnerability was only fixed in the next major version of a dependency

It was not. It was a bugfix.

[mtrezza]

It turns out that the PR was automatically opened in #185 yesterday. The reason this wasn't opened earlier was that there was no fix available. This confirms that your automated dependency upgrade process to remediate vulnerabilities works.

[wojtekmaj]

It doesn't. Dependabot raised a PR for you, but ultimately, the whole ecosystem waits for you to take action.

[mtrezza]

@wojtekmaj That is our policy across the organization. Please refer to my previous comments for the reasons why.

[MichaelDeBoey]

@mtrezza Any ETA on when you'll push a new release?