Skip to content

Roadmap: initial versionΒ #1

@43081j

Description

@43081j

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.json we manually keep up to date
    • For example, we could run through sv create and take a copy of the package.json into 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
  • 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions