This is a early stage RFC so the forums might be the best place to start.
Summary
There often exists dozens of packages which provide similar functionality. Adopting a consistent choice of third party package to provide a necessary feature helps in a number of ways, including; consistent code across the entire codebase, ease of testing and debugging, and potentially reducing overall bundle size and dependencies.
I propose some list which can state the projects preferred third party packages for specific common features/tasks.
Motivation
My attention to this was brought about by the recent listr to listr2 change and prompting within the CLI. Currently in general we use the prompts package but listr2 has first class support for enquirer built in. In general these two packages perform the same job but now I would argue we should have a preference for one over the other given our choice of other third party packages.
This could result in using two packages which offer the same functionality for little to no reason. We could help to avoid this by maintaining a list of preferred packages.
Details
I propose we examine the current package dependencies across the project and produce a list of packages we use for specific features. This process also allows identification of excess third party packages.
We can then include this list somewhere new contributors can see, such as the contribution readme/introduction online. This can simply be a list of feature/functionality, the package(s) we prefer to use to meet this feature/functionality and a brief description of why we made this choice. Eg:
Prompting
-
enquirerbecause it integrates well withlistr2and provides good breadth of functionality
I don’t propose this list indicate some inflexible choice of allowed packages. Simply as a gentle guide for new contributions to follow and use existing dependencies if possible.
Changes to this list, i.e. new third party package requirements, can be proposed/confirmed via a RFC which gives all maintainers/contributors a chance to voice their opinion on package choices. It also enforces a check to ensure we don’t needlessly add additional dependencies.
In theory new contributors could examine the projects dependencies themselves but often packages may not have overly descriptive names related to their functionality. Contributors may not be deeply embedded within the node ecosystem and so may not know of the top choice of packages for specific needs. This would simply make it easier for new contributors or indeed existing ones working on new areas to know which packages to use.
Reasons Against
It could be considered a sizeable amount of work to examine all current dependencies.
My main aim here is to seek a dialogue around this idea rather than set out a concrete implementation of it.