packagist
packagist copied to clipboard
composer
Add a version constraint tester/checker to the view package sidebar
I think we should include the functionality of https://semver.mwl.be directly in Packagist. I'd imagine a little input box and stability drop down on the right side on a package detail page which then opens a layover with the selected versions and lets you try different constraints.
cc @hannesvdvreken
Built into the version table section? Or a different one?
What would be the default values of the input? * and dev (which shows all versions), or ^1.23 (default for monolog atm) and stable?
@hannesvdvreken didn't even consider that, i suppose we already list all versions there so no need for a layover or anything can just add it there indeed.
I would keep the default an empty constraint with a placeholder text of ^1.23 as an example? Not sure what to do about the stability? Just a "min-stability" option without a value which forces you to select one? Otherwise I suppose dev so it's not confusing why it's showing everything?
Would you
- grey out non-matching versions (and make them non-clickable)?
- the inverse of the above: highlight matching versions?
- hide the non-matching versions and crop the list?
I think the default stability used when matching a constraint should be stable, as it is the default stability in Composer.
@stof the problem is that the list contains dev versions and it's confusing to have "stable" as the default choice with the list of versions showing everything including dev by default.
@hannesvdvreken I'd say make the matching ones bold and gray out the non-matching ones? I think cropping is not as helpful cause it makes it less obvious what you're skipping?
ok!
So: I see this as the most useful:
Pre-populate the input fields with the default current constraint (^1.23 for monolog) and stable as stable is the default by composer, as @stof pointed out.
Then make matching ones bold, and gray out the non-matching ones. This way, all versions are always visible (if you collapse the section, of course). And it makes it apparent what the current verion will be that will be installed and which versions match that constraint that composer adds to your composer.json file.
@naderman maybe the stability selector itself should be grayed out when no constraint at all is entered in the field (i.e. when you are not using the feature) ? Such situation happens because the list ends up having 2 different purposes here (the version switching, and the results of the matching)
@stof yeah, greying out the select would be a good idea.
Do you think we should create a new sidebar section instead?
I think as long as the gray ones still underline and are clearly visible as links we don't need a second list, and I'd go with what hannes suggested, and just have it active with stable by default.
IMO the field can be empty by default, and if empty well it's not filtering anything so by default it can be empty + stable. Then if you enter anything the stable kicks in as well.
As for highlighting vs graying out vs removing.. I'm not sure what's best, but that's kinda easy to tweak anyway :)
