Rename this module

[mcollina]

From a discussing with @lirantal on twitter: https://twitter.com/matteocollina/status/1610577242844708865?s=46&t=wpaDKCujckm07OZ7JAa3hg:

Unfortunately there is. I made some terminology mistakes at the beginning and they stuck, eg “everything is a plugin”. But also “plugins are encapsulated by default”. “fastify-plugin” is for creating reusable modules, not for application builders.

I think we should rename this module to @fastify/meta.

[jsumners]

I think this would cause way more confusion that it solves. We have already established that fastify-plugin is used for module creation. It's a core concept in the framework and ecosystem (also why we didn't namespace it with the other modules). Changing the name would be a bit hit in education (which we already have a problem with) and plugin maintenance. Just look at our org and all of the modules we'd have to go update; the project is equal to or greater in scope as the namespacing project.

If it were to be renamed, though, I'm not sure about @fastify/meta. How does that fix the "what does this tool do by only reading its name" problem? It adds metadata, sure, but it also changes the way a plugin operates (encapsulation breaking). I don't currently have a better name, but I don't think "meta" is it.

[delvedor]

I agree with what @jsumners said. Yes, in retrospect, it's a bad name, but changing it now could cause more problems than what it would actually solve. If we decide to rename it, it should be a name that is so good that it's impossible to say no :P

Some ideas:

• @fastify/share-plugin
• @fastify/decontextualize
• @fastify/plugin-maintainer-essentials

[fox1t]

I agree with @jsumners and @delvedor, but, as I said on that Twitter thread, it is impossible for me to unsee the issue with that name.
I want to give it a shot: we can use the "opposite" of encapsulate.

• fastify-expose -> @fastify/expose-plugin

Self-explanatory enough.

[Eomm]

I would add to the table:

• @fastify/sidecar-metadata: it is an optional way to set some metadata on a plugin

---

I think after collecting some ideas, we could just vote the proposed option 🔢 / or to not rename it 👎🏽

[climba03003]

Beware of we provide a option for encapsulate, so it by default exclude from encapsulation but also allowed to create encapsulation.

[Uzlopak]

I had a discussion a week ago wth liran tal about that issue in linkedin.
https://www.linkedin.com/posts/talliran_hey-fastifyjs-devs-a-thought-would-it-activity-7014228764804952064-bcKB?utm_source=share&utm_medium=member_desktop

I think the name, fastify-plugin, is good.

[delvedor]

Beware of we provide a option for encapsulate, so it by default exclude from encapsulation but also allowed to create encapsulation.

I would avoid this, encapsulation by default is a design choice.

[climba03003]

I would avoid this, encapsulation by default is a design choice.

Maybe you somehow mistaken what I am saying? It is a option in this package.
https://github.com/fastify/fastify-plugin#encapsulate

So, any name that imply it must escape the encapsulation will be wrong because you have the ability to control the behavior.

[jsumners]

Here's the thing, "plugin" has two simultaneous definitions, with one being a subset of the other:

1. a simple function that encapsulates logic (e.g. other plugins and routes)
2. a simple function that encapsulates logic in a distributable package with corresponding metadata (i.e. fastify-plugin has been applied to it)

The fact that a plugin can have its context exposed to ancestor contexts or not is not really the point.

[mcollina]

@jsumners +1. That's pretty much the sum of the discussion. This is mostly a utility module so that all the metadata needed by Fastify can be set in a convenient way instead of using global symbols.

(This is not part of Fastify to avoid individual packages to depend on Fastify itself.)

The question is how we fix this. It's confusing for most people, and I think we should tame this problem.
We do have a slot for releasing a Fastify v5 release next year (to drop both v14 and v16), so we might think of a breaking change as well.

[jsumners]

@fastify/annotate-plugin?

[mcollina]

@fastify/annotate?

[jsumners]

@fastify/annotate?

But what does it annotate?

[mcollina]

Plugins!

[Uzlopak]

Tomorrow we will not only annotate some symbols but encapsulate some additional checks and then we need a new npm package covering that behaviour.