-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some metrics of package quality #1
Comments
So caveats:
|
On 0.x.y versions, the x should define backward incompatible API changes, the same way as major versions on post-1.0.0 releases. |
All we can check is that the version is valid semver. |
APIs could somewhat be check by analizing the methods and their parameters and see if they are added or they change, in that last case it should be in a new major version (or new 0.x). It could be also done to check deleted methods and params and show a warning if they were not marked as deprecated in a previous version. |
If you can think of a way of doing that statically from an unbundled package tarball/repo, I'd certainly be interested. |
Maybe using esprima or something similar... For prototype defined ones should be somewhat easy, for instance methods ( |
Obviously being Javascript a dynamic language this could never be bullet-proof, but a statically analisis could be done in a high percentace of situations. |
yeah, I already have some need for esprima to come along at some point... but this is probably one of those spots where a PR would work best (even if it's just tests). |
Look at the exported thing; compare Added would guarantee at least a minor - deleted would guarantee a major - no observable changes is likely a patch. Obviously for 0.x versions (which nobody should still be using anyways; dock them for that regardless), obviously the second number is for breaking changes, and the third for additions. |
Per your request:
npm install
should be 100% of what's required in a given module to install all of its dependencies and/or dev dependenciesnpm test
should always run testsnpm explore foo && npm test
should always run foo's tests (ie, always publish test files)scripts
hash in package.json. Makefiles (or any ripoffs of same) are totally fine, but I shouldn't need to know how to use those to run 100% of important tasks:npm run foo
can alias tomake foo
, for example.The text was updated successfully, but these errors were encountered: