Change "package" for "extension"

👨‍💻 Framework Development » Framework Design
1

I find confusing to name our packages as “packages” and then divide them between “themes” and “extensions” when “theme” is just a namespace. It gets more confusing when dealing with npm packages.

The name “plugin” is also confusing because WP has plugins and there will be a Frontity plugin, but “extension” is not used anywhere else.

So my suggestion is to change our “packages” for “extensions”, even for the themes.

In frontity.settings.js:

module.exports = [
  {
    name: "my-site", // The name of your site.
    extensions: [
      "@frontity/mars-theme",
      "@frontity/tiny-router",
      "@frontity/wp-source"
    ]
  }
]

In the command line:

npx frontity create-extension

In TypeScript:

import { Extension } from "frontity/types"

interface MyExtension extends Extension {
  ...
}

In the project structure:

package.json
/extensions
frontity.settings.js

Then in the docs we make sure that people know they need at least 3 extensions:

You need at least three extensions: one theme, one router and one source.

And finally we can talk about local extensions which are the ones in your /extensions folder.

I’m not 100% sure. Any thoughts?

2

I agree.

3

:exploding_head:

4

Now your are wondering if it was the right decision! :laughing:

5

Yes, I still am :laughing:

6

@david?

7

Well, we are in some way extending frontity’s core, so I think extension is a good name, isn’t it?

8

EDIT: I put the poll on hold for now.

10

@orballo could you please share your latest concerns here? This is a huge refactoring so I’d love to be sure before starting.

11

Sure, my concerns where that depending on the context where we are talking about a package, it could be named package or extension even if the thing itself was the same.

For example, if we talk about @frontity/wp-source in relation with package.json we’ll call it package, but if we talk about @frontity/wp-source in relation with frontity.settings.js we’ll call it extension. It will be the same thing with two names depending on the context, and that might result confusing.

12

Good point.

What about calling them just Frontity Packages instead of Extensions? Does it help?

13

How would the key be called inside frontity.settings.js? frontityPackages? It seems redundant. Maybe the way to go is just to keep it as it is.

14

Yes, they would be named just packages but Frontity packages when you need to distinguish them from regular npm packages.