Roadmap

[lucacasonato]

Stage 0

• Usability improvements (Webhooks should also support content-type application/x-www-form-encoded  #33 and Webhooks should handle all event types #34)
• Add integration tests (Integration tests #43)

Stage 1

• Track download counts (Track download counts #57)
• Display download counts on website as a graph (like crates.io)
• Run deno info --json on ts/js files in the repository to get a dependency graph. Store in $NAME/versions/$VERSION/meta/deps.json. This tree should be a multi entry point graph with nodes and edges, not a simple tree. (feat: dependency analysis #62)
• Basic moderation. Do not allow people to register modules with "bad" words in the name or description. (Presumably there is some list somewhere one can match against.) (Moderation filters #58)
• Make deno info --json work with more modules (eg modules using decorators)
• Let registry quota be increased per user / org

Stage 2

• Run deno fmt on all files in repo and store list of failed files in $NAME/versions/$VERSION/meta/analysis.json
• Run deno lint --json on all files in repo and store list of failed files + the diagnostics in $NAME/versions/$VERSION/meta/analysis.json
• Run deno check on all files in repo and store list of failed files in $NAME/versions/$VERSION/meta/analysis.json
• Run other checks on repository (LICENCE & README.md file there, are dependencies pinned to specific version) and store this in $NAME/versions/$VERSION/meta/analysis.json.
• Better search (Improve module search #69)

Future

• Run deno doc --json on all files in the repo and store the output in $NAME/versions/$VERSION/docs/$FILEPATH.json
• Create & store a type stripped stripped version of all files in $NAME/versions/$VERSION/stripped/$FILEPATH.json
• A proper API
• Support for GitLab and BitBucket

[brandonkal]

Please ensure Stage 2 is opt-in for the module author. Also, a deno fmt report provides no value-add for the library consumer and will only generate noise.

[nayeemrmn]

Please ensure Stage 2 is opt-in for the module author.

That kind of destroys the point...

[brandonkal]

If it is not opt-in it will generate too much noise.

1. deno check will fail if parts of the code need to run with --unstable. I can document that in the README, but some automated scan will mark the module as bad. Just another false-positive.
2. Are you going to mark modules as bad because it uses tabs or prettier instead? That's nonsense. deno fmt output is entirely subjective and has no bearing on the usability of code.
3. deno lint is also subjective as well.

These are a few reasons why making any automated checks opt-in.

[littledivy]

The frequency at which a module is updated should be considered as well?

[jhechtf]

For the Gitlab / Bitbucket integration, what needs to be done to move those forward?