Repository navigation
Conversation
Change the axios dependency from the exact version 1.20.0 to the range ^1.20.0. An exact pin in a library dependency prevents deduplication in consumer applications. When an application also uses axios, the package manager installs two copies. The AxiosInstance and AxiosError types from the two copies are then not compatible. The pin was added in openfga#363 as a temporary response to the axios 1.14.1 supply chain attack. openfga#363 states that the pin can change back to a range when a clean axios release is available. Applications control the versions they install with lockfiles and release-age policies.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review. WalkthroughThe ChangesAxios Dependency Range
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~3 minutes Change: Other Suggested reviewers: Merge Risk: ⚪ Minimal · up to Consumers can resolve compatible Axios 1.x versions starting at 1.20.0, while the supplied lockfile remains at 1.20.0. No actionable merge-blocking risk is evidenced. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Some tools did not complete. Review the errors below. 🔧 ESLint
ESLint install failed: dependency version conflict. Check your lock file or package.json. 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. Comment |
Change the
axiosdependency from the exact version1.20.0to the range^1.20.0.Description
What problem is being solved?
The SDK pins
axiosto an exact version. Many applications that use the SDK also useaxiosdirectly. The exact pin causes these problems for those applications:axios. If the application resolves a differentaxiosversion, two copies are installed.axiostypes:AxiosInstanceindist/base.d.tsandAxiosErrorindist/errors.d.ts. With two copies, anAxiosInstancethat the application creates is not assignable to the SDK type. Also, theAxiosErrorfrom the SDK is not the same type as theAxiosErrorin the application.v0.9.7) pinsaxios@1.19.0, which has 9 published advisories.mainpins1.20.0(chore(deps): bump the dependencies group with 4 updates #477), but that change is not released yet. Applications cannot get anaxiospatch release until the SDK publishes a new version. To work around this, applications must addresolutions/overridesentries.How is it being solved?
#363 added the exact pin as a temporary response to the
axios@1.14.1supply chain attack. The "Follow-up" section of #363 says:axios@1.20.0is a clean release after1.14.0, so this PR does that follow-up.The caret range
^1.20.0keeps1.20.0as the minimum, so no consumer gets a version below that. Applications control which version they install. They do this with their lockfiles and with release-age policies such as YarnnpmMinimalAgeGateor pnpmminimumReleaseAge. An application can make that decision. A library cannot make it for all of its consumers.I did not change
axiosto apeerDependency. That change requires all consumers to installaxiosthemselves, which is a breaking change. A caret range fixes the problems above and is not a breaking change.What changes are made to solve it?
package.json:"axios": "1.20.0"→"axios": "^1.20.0".package-lock.json: The root dependency entry is updated. The resolved version is stillaxios@1.20.0.References
Request: after this PR is merged, please publish a release. Then consumers can get the
axiosfix from #477 without aresolutions/overridesentry.Review Checklist
mainnpm ci,npm run build,npm run lint(0 errors), andnpm test(251 passed, 0 failed) pass on Node 24.Summary by CodeRabbit