`"latest"` support

[yowainwright]

Hello! Love this module!

Any considerations around "latest" support?

In Example:

{
  "lodash": "lastest"
}

Thank you!

[omichelsen]

Not sure I understand? If you add "latest" as a version in your package.json it works fine with compare-versions:

"compare-versions": "lastest"

[yowainwright]

@omichelsen thanks for your fast response!

It's might be a me thing—usually is. 😄 I'll try to reproduce the issue in a Stackblitz in a bit. I'll close if I can't reproduce the issue! 👌

[yowainwright]

Here's the reproduction:

• https://stackblitz.com/edit/typescript-fhup6r?file=index.ts

Looking forward to your feelings on this!

• I could see capturing "latest" and doing something (flagging it in some way) or just setting "latest" to latest, haha

Thanks again!!!

[omichelsen]

Ah I see, you want to use "latest" as a version name to compare against. I don't see a way that this would work, since the code running your comparison has no idea what "latest" means (which version is newest at any given time). It would be equivalent to either rejecting or accepting everything.

[yowainwright]

That, along with workspace protocols, is a current limitation of the api, right? Perhaps it should be documented? Or:

1. An optional options argument could be added to compare-version functions to let the executor enable meaning to their sorting/comparing function invocations.
2. Sorting/comparing checks could be done by traversing package.json's.
3. Sorting/comparing checks could be done by capturing latest or workspace protocols via checking what "latest" actually is in a registry.

• Option 3 is weak as it would degrade compare-version performance but options 1 and 2 are viable.
• Documentation updates would work too! I had to update code in a few places to mitigate this issue so it might be good for other users to know about this limitation so they can write code accordingly.

Thanks so much for the awesome utility!

Let me know if I can help. I feel this issue is important to document as compare-versions is very useful for monorepos but lastest and workspace protocol support is a limitation that's good to be aware of when using the compare versions utility!

Sorry if I'm misunderstanding any of the api 💛🙏

[omichelsen]

Thanks for describing your use cases. I think these examples goes beyond the scope of this project though. This is a tiny (few hundred bytes) library intended to compare version strings according to the official semver spec (with a few additions). It has no concept of npm, yarn or any other package/module manager systems controlling the "latest" concept you are describing.

I'm not sure how you are using it in your monorepo work, but maybe you need a (new) more specialized library? If you were to create such a library, it could perhaps still use the basic functionality of compare-versions, but add features specific to npm (package.json) usage?

I'd be happy to clarify the documentation with any improvements you might think of. Please feel free to open a PR 😀

[yowainwright]

@omichelsen sorry for my slow response.

Your comment resonated with me:

Small library (and matching of semver spec).

I wouldn't want to overcomplicate the API or docs as this library is SO HELPFUL as is.

Here's a contrived example for reference if anyone comes across this same sort of thing.

I'll subscribe to this issue and am happy to support more if needed.

• Feel free to (at)me later. I'm specifically using this lib at work and here, here, here, and here for monorepo-related functionality.

Feel free to close the issue from my perspective, @omichelsen!

Thank you!!!