-
-
Notifications
You must be signed in to change notification settings - Fork 1
Description
For this, I imagine a microsite which lists each of the popular frameworks in use today.
For each one, we should render the dependency tree of its starter kit (or equivalent). This means we're rendering the dependencies of a typical install rather than the framework itself.
Each of these dependency trees should be annotated with all known e18e-related issues, PRs, etc.
Features
Main page
- List of frameworks
- Each framework has a "health" score (TBD)
Framework page
- Show the dependency tree
- This can be a snapshot of a typical
package.jsonwe manually keep up to date - For example, we could run through
sv createand take a copy of thepackage.jsoninto the microsite's repo - Render the tree as-is (all dependencies, i.e.
npm ls --all) - Annotate dependencies with ongoing issues and PRs
- Annotate duplicates
- Annotate redundant/unmaintained/etc packages
- Annotate trusted publishing & provenance
- This can be a snapshot of a typical
- Show the framework name
- Show the framework "health" score (TBD)
Annotations: Issues/PRs
All ongoing issues and PRs should be attached to the nodes they're related to (may be multiple).
For example, if chalk is in the tree, we probably have an open issue/PR to move off it. We should link that node to the issue/PR with some brief text on what it is.
These annotations can be curated, as we can just submit a PR when we open new ones. We don't need to automate them.
Annotations: Duplicates
We should manually curate a list of packages which do the same job (in the scope of these frameworks for now).
Using this list, we can highlight in the tree nodes which have equivalent functionality.
These may not be the same importance as an issue/PR since it may be an active choice to keep both for some reason.
Annotations: Unmaintained, obsolete, etc
We should annotate nodes which represent packages which are unmaintained, redundant, etc.
This again can be a curated list focused on these framework stacks.
Annotations: Provenance & Trust
If we can find a good way to determine if a given package was published using trusted publishing, it'd be good to mark this up.
If that is too difficult, we could at least show if the package has provenance publishing or not.
Scores
It would be nice if we could have a numeric score some day, probably /100.
This shouldn't be human-chosen though, and should ideally come from tests or something. For example, we could test for existence of duplicates, or unmaintained packages, etc. And those metrics would affect the score.