criticality_score VS typescript-eslint

TL;DR: I could extend the Criticality Score algorithm with usage metrics from Ecosyste.ms API and apply it to all open source accounts under the Open Collective, so we have a new ranking now! I also made it possible to change the weights of each parameter so that you can try the algorithm by yourself.

As mentioned in the description, the score is based on the OpenSSF criticality score. I dropped some of the features that are difficult to get from GitHub due to crawl limits, as well as changing some weights.

I am doing some research based on the criticality scores assigned by this project to different technologies: https://github.com/ossf/criticality_score

LF OpenSSF "criticality score" for 100,000 Github repos, https://github.com/ossf/criticality_score & https://docs.google.com/spreadsheets/d/1uahUIUa82J6WetAqtxCM...

> Generate a criticality score for every open source project. Create a list of critical projects that the open source community depends on. Use this data to proactively improve the security posture of these critical projects ... A project's criticality score defines the influence and importance of a project. It is a number between 0 (least-critical) and 1 (most-critical). It is based on the following algorithm by Rob Pike

Top 20 projects:

> node, kubernetes, rust, spark, nixpkgs, cmsSW, tensorflow, symfony, DefinitelyTyped, git, azure-docs, magento2, rails, ansible, pytorch, PrestaShop, framework, ceph, php-src, linux

For more information, please check the Criticality Score repo itself.

Typescript-eslint can assist in this task. This tool helps identify all instances of unsafe any usage. Specifically, all usages of JSON.parse can be found and it can be ensured that the received data's format is checked. More about getting rid of the any type in a codebase can be read in the article Making TypeScript Truly "Strongly Typed".

> Only lint files that have changed? How hard that is?

Quite hard, especially since type-aware rules from e.g. https://typescript-eslint.io/ mean that changing the type of a variable in file A can break your code in file B, even if file B hasn't changed.

The article only touches this: when converting to TypeScript, `any` is useful, but in the end you don't want this type in your codebase - so don't forget to use typescript-eslint [0] and turn on those no-unsafe-* rules which guard against `any` leaking into your code.

[0] https://github.com/typescript-eslint/typescript-eslint

By convention, React components should be named in PascalCase. @typescript-eslint has the config we need, and though we can't specifically target React components, we can target variables (and set some other conventions while we're at it):