Create an index of "frontity" packages

[mmczaplinski]

Description

As more users are publishing their own frontity packages, we should start tracking them so that we can provide an official “index” of frontity packages that can be installed.

In the future we can provide an official, searchable list of frontity packages on our website and extend the CLI so that each one of them could be installable with just frontity install-package <package-name>

Examples

Gatsby has an ecosystem of “plugins” that basically serve the same purpose as frontity packages: https://www.gatsbyjs.org/plugins/

Possible solution

There are several related tasks that we need to accomplish:

• Create an index of packages as an editable database. This should be editable both manually and through some sort of an API. We could probably get away with just a notion page for the moment. Later, I think we should create a serverless function that connects to a data storage somewhere.
• Manually collect a list of already existing frontity packages (can search on npm/github)
• Establish a convention that each npm package with a frontity-* prefix is an installable “frontity” package.
• Create a cron job that periodically adds all those packages to our index.
• Extend the CLI to allow installing a frontity package by doing just frontity install-package <package-name>
• (nice to have) Update the frontity CLI to by default create a package with a frontity- prefix followed by 2 random words (e.g. frontity-daring-fireplace) so that it’s instantly publishable under that name.

[SantosGuillamot]

I think it’s a great idea, looking for and installing frontity packages should be as easy as possible .

Regarding the Gatsby plugins, I think they are fetching them from the monorepo, in the packages folder. Would it be possible to do somethings similar for the official packages in Frontity?

[mmczaplinski]

@SantosGuillamot

I think they are fetching them from the monorepo,

As far as i can tell the users can submit the plugins to gatsby https://www.gatsbyjs.org/contributing/submit-to-plugin-library/

They are using algolia.com for the search by the way, maybe we can use it as well if it’s simple to set up. I think we should fit in the free tier easily.

[SantosGuillamot]

You’re totally right, I had just seen the official ones but there are also external plugins.

Algolia seems nice, I’m going to take a look and I’ll post here my findings.

[SantosGuillamot]

I just run a quick test and the integration between Algolia seems to be easy and pretty nice. We still have to investigate a bit further how it works but this is what I achieved so far:

What I did was getting all the npm packages with the keyword frontity from this url and imported the json manually to Algolia: https://registry.npmjs.org/-/v1/search?text=keywords:frontity&size=250. It should be easy to automate to it and get the info once/twice a day.

From that I installed the algoliasearch npm package and configure it for a specific page. It was fairly simple.

Some things to consider:

• How are we going to filter the packages. Maybe just by the frontity keyword isn’t enough.
• We’ll need to agree on a format for the packages.
• We have to figure out how do we want to show them in the web.

[nicholasio.oliveira]

I think we need a way for packages to be submitted to a “central repository” even if it’s just adding a github URL to a text file through a Pull Request.

That way the frontity team would have at least some control of what’ getting added to the repo.

[luisherranz]

Yes, for now I just would npm keywords. Maybe @santosguillamot is right and the frontity keyword is too general, and it would be better to promote a frontity-package keyword instead.

For “official” namespaces, we can use specific keywords:

• source: frontity-source
• analytics: frontity-analytics
• comments: frontity-comments
• newsletter: frontity-newsletter
• share: frontity-share
• …

That way we can filter those namespaces directly by searching on npm.

When we release a new version of a namespace, we should release a new keyword:

• source v2: frontity-source-v2

We can add a new "frontity" field to the package.json file with our own structured data but that is not searchable in npm. Depending on how users are going to share/search for the packages, that may be important or not.

I agree with @nicholasio.oliveira that we need the ability to “officially approve” the packages, especially for the official namespaces where it’s important to know that a package is compliant with the namespace needs. We could provide a badge for the approved packages.

---

Regarding this, I just want to add an idea for the future (far future) I’ve been thinking about: we should release our own dependency system to allow packages to specify.

• Which namespace they implement
• Which other namespaces they require
• Which other namespaces they support

This will allow a theme to specify that it requires a router and a source-v2 and that it supports comments, share, and newsletter.

{
  "name": "my-awesome-theme",
  "keywords": ["frontity", "frontity-theme"],
  "frontity": {
    "implements": ["theme"],
    "requires": ["router", "source-v2", "html2react"],
    "supports": ["comments", "share", "newsletter"]
  }
}

With this, we could create a powerful UI to inform users that they are not meeting the requirements for a package, or suggest them to install additional packages.

In this system, we could add fallbacks to install packages automatically to meet the packages needs:

{
  "name": "my-awesome-theme",
  "keywords": ["frontity", "frontity-theme"],
  "frontity": {
    "implements": ["theme"],
    "requires": [
      {
        "namespace": "router",
        "fallback": "@frontity/tiny-router"
      },
      {
        "namespace": "source-v2",
        "fallback": "@frontity/wp-source"
      },
      {
        "namespace": "html2react",
        "fallback": "@frontity/html2react"
      }
    ],
    "supports": ["comments", "share", "newsletter"]
  }
}

That way if the user installs my-awesome-theme, everything is fine because Frontity can use the fallbacks to meet the rest of the requirements. But if he/she wants to use @frontity/wpgraphql-source instead of @frontity/wp-source, it’s also fine because Frontity won’t apply that fallback.

There is a bit more to this dependency system, but I just wanted to share it here as something I’ve been thinking about to simplify package installation for not-so-technical users in the future.