Closed BitBrit closed 1 year ago
Hey @BitBrit good point. Most of the time dates are not that useful because after updating the library to the next e.g. major version, it can still receive minor or patch updates in the future making timelines like a@1.0.0 a@2.0.0 a@1.0.1 So for now it sorts based on dates, but then compares based on semversion and skips all that are not major.minor.patch tagged.
But in case of semversion lack maybe the solution would be to add support for date-based comparison. I guess in the first iteration, it could be done behind the explicit flag.
Hi @BitBrit , bit with the same bug for local dependencies. https://docs.npmjs.com/cli/v7/configuring-npm/package-json#local-paths
But in case of semversion lack maybe the solution would be to add support for date-based comparison. I guess in the first iteration, it could be done behind the explicit flag. For non-standard semversion, it may lack the dates as well. You can just print a warning about such packages, ignore them and proceed with usual check for other packages. Just a quick thought.
Would love to take a spin of this package once the issue is resolved. 👍
Hi, so I added a flag to allow non-semversion packages too. In such case, they will be compared using dates and not versions.
https://github.com/pilotpirxie/dependency-time-machine/pull/2/files
For now, it's behind an experimental flag --allow-non-semver
According to the package.json specification it is possible to have dependencies that don't conform to the semver specification. Notably, URL and file dependencies.
Is it possible to handle these in a graceful way that allows the tool to continue creating its timeline?