linting code?

[Stuk]

I know that this project is code agnostic at the moment, but a metric like this actually indicates something about the quality of the code.

The presence of .jslint.conf, .jshintrc or .eslintrc indicates which linter to use, and the results of the linting could inform the rating.

[IanVS]

👍 I like this idea. If a package claims to follow certain conventions (as specified in their lint config), it should be penalized for not actually following them.

[alexfernandez]

I like the idea too, but it is a bit ambitious at this stage. Requires downloading tens of thousands of packages and linting them. Each full update takes almost 24h right now as it is.

[IanVS]

True, didn't think of that. There are a lot of packages out there.

I see an opportunity here for you to create a paid service around this module. Something along the lines of "pay money and we can run more tests on your package, giving a more meaningful result." Granted, it's not a very well thought out idea, but it's an idea. :)

[alexfernandez]

It is doable right now, e.g. by npmjs.com who already keep copies of all modules. For this project, I think that keeping to external measures (like checking if there is a build and it passes) might be more productive. At least until we figure out how to charge for our services :)

[Stuk]

It might be easier to scale if linting is done on-demand instead of ahead of time.

[alexfernandez]

Yes, we are planning to do both things: one weekly round with all packages, and also on-demand updates. See #15. But we need the weekly round in order to be able to rank packages. When we are hyper-famous and all packages have their badges, we can stop doing the weekly update.