Just pulling together all the various ideas into an initial roadmap. If something is missing or out of scope, shout up and we can edit the list.
Basic metrics
These can all be computed today but usually through multiple requests at runtime, so the benefit here will be storing them once (essentially caching them).
- Package type (ESM, CJS, dual, etc.)
- Number of deep dependencies
- Number of licenses deeply, and which ones
- Minimum engine version deeply
- Note that this is the lower bound of the highest constraint. For example, if I depend on A (
node > 14) and B (node > 16), our minimum node is 16
Expensive integrations
These are third party tools we can run at runtime but cost a lot, so would be better to compute once and cache.
- publint
- This already produces many useful metrics and warnings
Analysis capabilities
These are things we can't find through npm's API because of query limitations. So if this API has the ability to query these, we should have special endpoints for each of them.
- Dependents of a package
- Sorted by number of downloads, and limited or paged
Just pulling together all the various ideas into an initial roadmap. If something is missing or out of scope, shout up and we can edit the list.
Basic metrics
These can all be computed today but usually through multiple requests at runtime, so the benefit here will be storing them once (essentially caching them).
node > 14) and B (node > 16), our minimum node is16Expensive integrations
These are third party tools we can run at runtime but cost a lot, so would be better to compute once and cache.
Analysis capabilities
These are things we can't find through npm's API because of query limitations. So if this API has the ability to query these, we should have special endpoints for each of them.