Microsoft's Top NPM Dependencies

Looking at Microsofts' public git repos to find their most frequently declared NPM dependencies 📊

Recently, we showed how to query for the most frequently depended-on Go modules from Google’s GitHub org. Similarly, we can look at the NPM dependencies (declared in a package.json file) for all JavaScript (or TypeScript) repos. This time, we’ll look at Microsoft’s 4k+ public repos.

We’ll start with a query to collect the contents of all the available package.json files across their repos:

	SELECT
	repo.name,
	github_repo_file_content('Microsoft', repo.name, 'package.json') package
	FROM github_org_repos('Microsoft') repo
	WHERE package IS NOT NULL

view raw microsoft_package_json.sql hosted with ❤ by GitHub

Which we’ll export to a table for additional (faster) querying. We can use the available JSON functions to extract and parse the contents of the 871 package.json files we found:

	SELECT
	count(*), deps.key
	FROM package_json, json_each(package, '$.dependencies') deps
	WHERE json_valid(package) = 1
	GROUP BY deps.key ORDER BY count(*) DESC LIMIT 100

view raw count_package_json_deps.sql hosted with ❤ by GitHub

Which yields the following top 10 most frequently declared dependencies in all the package.json files:

1. react (84)

2. react-dom (76)

3. lodash (63)

4. uuid (47)

5. fs-extra (46)

6. semver (42)

7. vscode-nls (39)

8. request (37)

9. glob (35)

10. vscode-extension-telemetry (34)

The full output and distribution can be found here. These results are not that surprising, as the top 10 are generally popular dependencies.

Next Steps

More interesting and actionable insights could come from extending or repurposing the above queries:

• Collect this data for the repos in your own organization (what dependencies are we most reliant on throughout our codebases…and how “healthy” are those projects)

• Examine package-lock.json and yarn.lock files for all dependencies, not just immediate ones

• Examine other aspects of a package.json file - declared license, scripts, node version - and possibly use it to enforce standards (all JavaScript repos should have a lint command, all should have an author listed, etc)

• Examine consistency of versions across commonly used dependencies (what’s the distribution of React versions used?)

• Join with the NPM registry to find how out of date dependencies are - and maybe alert when they become too stale (a la dependabot)

• Join with git blame to find who adds which dependencies and when