refactor: standardize entry points and project structure

[Tony133]

Proposal:

Renamed the main plugin file to index.js to provide a standard entry point for the package. This simplifies imports and follows the common pattern used in the Fastify ecosystem.

Changes:

• Rename plugin.js → index.js
• Updated package.json main field.

See PR reference:

• refactor: standardize entry points and project structure fastify-url-data#188

[jsumners]

There's really no need for change.

[Tony133]

There's really no need for change.

I’ve submitted this change request in only 4 or 5 repositories; the others all have an index.js file. As I mentioned earlier, the goal is simply to keep the repositories well-organized ( See the answer here: fastify/fastify-url-data#188 (comment)), and I think it will be helpful for all members 😉

[jsumners]

Both of these are already "well organized." The primary, or only, source code for the plugin is in an appropriately named plugin.js file. The index.js convention is tied to the conventional structure of a website and the default naming of the primary page. It implies there is other source code that branches off the main entry point. That's not the case in these repos.

[Tony133]

Both of these are already "well organized." The primary, or only, source code for the plugin is in an appropriately named plugin.js file. The index.js convention is tied to the conventional structure of a website and the default naming of the primary page. It implies there is other source code that branches off the main entry point. That's not the case in these repos.

All the other plugins have an index.js file, while some don’t they have different names. I used the wrong term: “organize.” What I meant to say is that keeping all the plugins consistent with the same file structure, folders, names, index.js entry points, etc., doesn’t seem like a bad idea to me.

[jsumners]

What I meant to say is that keeping all the plugins consistent with the same file structure, folders, names, index.js entry points, etc.

How does that benefit these independent projects? Why does the structure of another project's code affect the structure of some other project's structure?

These changes are not inconsequential. They will introduce, at a minimum, annoyance when navigating the code history. I commented on the ones I have an interest in, but I noticed in another that an index file was created simplely to point to another file in a new directory. That introduces many file resolution cycles and an annoyance when navigating the code: clicking in to what one thinks is the entry point file only to see that it's at a different place. The manifest clearly states what the entry point is to both the runtime and the human.

My reviews are not blocking reviews. I just don't see the point in these changes.

[Tony133]

How does that benefit these independent projects? Why does the structure of another project's code affect the structure of some other project's structure?

To answer your question about how this benefits independent projects: the main goal isn’t to change the logic of this specific plugin, but to reduce the cognitive load for contributors who move between the various projects in the Fastify ecosystem.

When every plugin o library follows the same pattern (structure, entry points, naming conventions), it becomes much easier to automate routine tasks and maintenance. While contributing to many repositories over the past few months, I’ve noticed that I often have to stop and examine the package.json file or the file tree just to identify the actual entry point.

Personally, having a predictable index.js file helps me (and potentially new contributors) immediately understand the structure without effort. It’s about creating a “Fastify standard” that makes the entire ecosystem feel like a single cohesive environment rather than a collection of different styles.

[jsumners]

The manifest clearly states what the entry point is to both the runtime and the human.

[Tony133]

The manifest clearly states what the entry point is to both the runtime and the human.

You're absolutely right, the manifest is the source of truth for both the runtime and anyone looking for the technical entry point.

My point is more about visual consistency and 'convention over configuration' across the organization. While the manifest tells you where to look, having a standardized structure allows a developer to navigate the code almost subconsciously, without having to open the package.json as a first step every time they switch between plugins or library. 😄

I’m happy to follow the consensus of the team on whether this level of standardization is desired for the ecosystem or if we prefer to keep each repository's unique structure 😉

[jean-michelet]

Just saw your comment, @jsumners.

I’m biased toward cleaning and harmonizing everything up, but that’s more of a personality trait than a rational position, so I don’t have a strong opinion.

If you think this is useless and eventually annoying, we can reject the PRs.

[gurgunday]

I'm also fine with either way, but I guess this doesn't hurt

[Fdawgs]

In the same camp as @jean-michelet, making the plugin repos uniform is nice!