Add ability to install older version of package (feature suggestion)

[bobwhitelock]

Hi - Ellie's really useful, thanks for making it 🙂. Hopefully this is the correct place to suggest features.

I just had the situation where I wanted to check if a certain behaviour in a package was a regression. I was able to check the behaviour with the latest version of the package, but when I tried to check it with an earlier version (still compatible with Elm 0.18) I could see no way to change which version is installed. For this sort of situation it would seem useful to be able to switch to an earlier package version, although by default the latest version would still be installed.

Do you think this would be possible/fit within Ellie? And if so how tricky would it be to add? I could look into adding this myself, but wanted to check first if it's the kind of thing you'd be interested in adding, and also how involved you think this would be. Thanks

[lukewestby]

I think the trickiest thing about this would be having good answers for UX questions. The technical aspects are easy enough.

• What does the UI look like for selecting a particular version of a package
  • when the user is searching for a package they haven't installed yet?
  • when the user is modifying a package that is already installed
• How does the UI guide the user to select a package version that exists?
• How does the UI guide the user to select a package version that is compatible with the Elm version of their Ellie (Ellie can run both 0.18 and 0.19 so that old Ellies still work)?
• Is it actually okay for the user to select something invalid and find out that their selection didn't work by running the compiler?

[bobwhitelock]

Thanks for your reply! Some thoughts on your questions, though I don't know a lot about the project so I can't say if all of this is reasonable/the best option:

• What does the UI look like for selecting a particular version of a package
  • when the user is searching for a package they haven't installed yet?
  • when the user is modifying a package that is already installed

In both cases it might seem reasonable to show this alongside the latest version as currently shown for a package, maybe as a small arrow (^) which can be clicked to display a drop-down of available versions.

I imagine the standard use case in ~95% of cases would still be to just want to install the latest version, and so most people could proceed with the same interaction as they do currently, without knowing/caring that this feature exists. But in the ~5% of use cases where you do want a different version, either before or after installing a package, the option to do this is in a logical place where you'll look first (if I remember correctly this is where I looked first when looking to see if this was an option before creating this issue).

• How does the UI guide the user to select a package version that exists?

I would imagine it should only be possible to select a package version which exists, as these should be the only versions available in the drop-down. Maybe the latest major version of each package could be highlighted in this list as these are the most likely versions to be installed (as they are the only ones with API changes, and most likely to have major additions), similar to the main packages site.

• How does the UI guide the user to select a package version that is compatible with the Elm version of their Ellie (Ellie can run both 0.18 and 0.19 so that old Ellies still work)?

I couldn't see how to switch Ellie back to compiling 0.18, and am not super familiar with all the changes in 0.19 yet (as it was released since I made this issue!), so possibly don't know much about how compatible things are for both Elm and Ellie, but: presumably there's some way to determine up-front which Elm versions a version of a package is compatible with? Or can this only be done by attempting to compile it with that version?

If the former then this could be used to determine whether to either not display or grey out a particular version of a package in the version select drop-down. If the latter then attempting to compile with a given version of a package would need to be used instead.

• Is it actually okay for the user to select something invalid and find out that their selection didn't work by running the compiler?

It doesn't sound ideal, so if possible it would seem better to not display invalid versions of a package at all. But if selecting and attempting to compile with an invalid version is the only way to tell if it's invalid, then I guess this would need to be done.

[jhf]

I'm trying to check if a regression was caused by a package upgrade, and to identify change.
It would have been really helpful if I could have added a suffix to specify the version, as this is a rare case indeed, and I don't think a UI should be devised for this.
So looking to yarn and npm I was hoping that mgriffith/[email protected] would list that specific version, and allow me to install it. Normally I'd type mgriffith/elm-ui and only see the latest version.
That would allow me to install different versions, when needed, without needing to modify the UI.