Searching

The current searching on hex.pm can lead to a lot of false positives. For example, searching for openid authentication:

gives results that match on either or both terms. In this case the authentication term is resulting in a lot of noise completely unrelated to openid.

There are a few different potential solutions. The first, and easiest, would be to change each word to an and search instead of an or search. Giving higher priority to the order of the terms themselves. With openid authentication openid would have higher sort priority than authentication.

The second option would be to use Nx to build a semantic search function for Hex. @seanmor5 wrote about this on the DY blog recently: https://dockyard.com/blog/2022/09/28/semantic-search-with-phoenix-axon-and-elastic and https://dockyard.com/blog/2023/01/11/semantic-search-with-phoenix-axon-bumblebee-and-exfaiss

We could also explore other search methods. TBH as much as it would be fun to implement Nx I think changing the query from or to and would be the best ROI.

Keywords

Prior works

npm spec: https://docs.npmjs.com/cli/v6/configuring-npm/package-json#keywords
npm search: https://www.npmjs.com/search?q=keywords%3Aauthentication

cargo spec: https://doc.rust-lang.org/cargo/reference/manifest.html#the-keywords-field
cargo search: https://crates.io/keywords/authentication

Adding keywords to Hex will allow for categorical deep linking and scoped searching. This is something I feel is necessary as the Elixir ecosystem continues to grow. First allowing for consumers to easily and quickly find relevant packages or browse a list of relevant packages. Second to incentivize producers if their efforts are more easily discoverable.

I would recommend the following update to the mix.exs spec:

  def project do
    [
      app: :my_app,
      version: "0.0.1",
      elixir: "~> 1.13",
      start_permanent: Mix.env() == :prod,
      elixirc_paths: elixirc_paths(Mix.env()),
      consolidate_protocols: Mix.env() != :test,
      package: package(),
      description: description(),
      source_url: @scm_url,
      docs: docs(),
      deps: deps(),
      keywords: ~w{live_view_component authentication}
    ]
  end

Keyword normalization

@ericmj voiced the concern around similarly intended keywords. For example: LiveComponent and live_component. To further illustrate this we could add live-component. I believe we can account for this by normalizing the keywords during publishing:

def normalize_keyword(keyword) do
   keyword |> underscore() |> downcase()
end

this should also happen when querying against a keyword. We store one normalized version of the keyword. There should, however, be a recommended format in the documentation and I would recommend the downcased version of a keyword phrase.

Deep linking

Allowing projects to deep link into keyword categories will provide value for consumers. For example, https://phoenixframework.org could deep link directly from its site or documentation to https://hex.pm/packages?keywords=live_component

Scoped searching

Searching within a keyword scope provides additional value when the keyword results are too large. Proposed url: https://hex.pm/packages?keywords=live_component&search=authentication

Multiple keywords

I've used keywords plural as they query param. It opens the possiblity of providing a bisection of two or more keywords: https://hex.pm/packages?keywords=live_components+authentication similiar to the search proposal above I believe this should be an and