Hunting down modules

I wanted to do something like Haskell’s QuickCheck in Elm:

  • I googled for “elm quickcheck”, got NoRedInk/elm-check as a first result. Trying to install, the module is not available for 0.19.
  • Looking at the GitHub repo, I noticed it suggests using elm-community/elm-check instead. Great, installing that. But that’s not available for 0.19 either!
  • I see, there’s another deprecation notice saying to use elm-community/elm-test, here I go!
  • …or not, that one is not available for 0.19 either. But it says to use elm-explorations/test.
  • Whew, this one actually installs.

This happens to me with Elm modules a lot. It’s not a very good user experience, can we do something about it?

3 Likes

Heard the quality of google search results complained about a lot. It isn’t a problem that I have experience myself, as I tend to start my searches at the Elm package site:
https://package.elm-lang.org/, which serves up the 0.19 packages by default. So the best thing you can do about it is to bookmark and use that. As to the search engines, I’ll leave that for someone else to answer.

1 Like

I will use the specialized package search when possible, good suggestion, thank you. The trouble is that Google is better when I don’t know that well what I am looking for. (Searching for “quickcheck” returns zero results on the package site. Makes total sense, but that’s why Google is helpful.)

Maybe it would be a good idea for us to find some way to make test to appear on a search for quickcheck? Since that’s a pretty standard name for people coming from other functional languages it would make sense I think.

There are some hardcoded hints in Search.elm that give suggestions for searches like “spa” and “scrollX”. Maybe it fits there?

1 Like

I use google a lot as well. I only do this because of the limited search-facilities on the package-site.

How does other communities handle this? Does Rust / Swift / Node.js / ? have a really cool approach to this problem? Can we perhaps do better?

I suppose forking/extending/presenting an improved version of the package-site would spark some interest in improving that flow, once the options have been laid out.

I think it could be a cool project with a lot of upside for the community! :sunny:

Maybe it would be nice if:

  1. If it was possible to mark packages as deprecated, like npm where a big red box is shown on the package page. Example: https://www.npmjs.com/package/parse-stack

  2. Package authors were diligent about adding notes about packages being deprecated on GitHub, linking to successors.

  3. Packages that aren’t compatible with the current Elm version had a big warning at the top. I know that they won’t show up when searching directly on package.elm-lang.org, but you can access them via Google. Example: https://package.elm-lang.org/packages/NoRedInk/elm-check/latest/

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.