Versioning & package tools
Dependency and version questions cross ecosystems constantly: whether an npm range actually matches a version you're about to publish, whether a package.json's exports field resolves the way a bundler expects, or how a Maven dependency reads once translated to Gradle's DSL. This page has version and range tools for semver, PEP 440 and several other package managers, plus editors for package.json and its exports map.
Use the semver calculator to compare versions and test npm ranges directly, and the PEP 440 version checker for Python's own, stricter version scheme, since the two aren't identical. The package.json exports visualizer specifically tests subpath exports against both import and require resolution, which catches mismatches a plain JSON viewer won't show. The Maven to Gradle converter and package version tools for Composer, NuGet, Go and Cargo round out cross-ecosystem work, all running locally.
8 tools
Compare and test version ranges
Edit package.json and exports
Versioning & Packages tools FAQ
Ranges like ^1.2.3 or ~1.2.3 follow specific semver rules for which parts are allowed to change, and it's easy to misread how a caret range treats a 0.x version differently from a 1.x one. The semver calculator tests a version against a range directly so you can confirm the match instead of reasoning through it by hand.
It's valid under PEP 440 as a pre-release, and it sorts before the final 1.0.0 release. The PEP 440 version checker normalizes and sorts a list of Python versions and checks them against constraint strings, which is more reliable than comparing them as plain strings by hand.
The exports field can map different files to import and require conditions, and a mismatch — like a CommonJS-only file mapped to an import condition — breaks resolution for one but not the other. The package.json exports visualizer tests subpath resolution against both conditions so you can catch that before publishing.