If a project mainly consists of JavaScript it should be a JavaScript project, no?
But the wiki also has an embedded script-ish language (letting people create macros/templates for specific purposes and re-use them across multiple articles). That's JavaScript-based, and so is implemented in node.js. And there's a WYSIWYG editor for the wiki pages, which is a couple of MDN-specific plugins we've developed, plus off-the-shelf components (the editor + jQuery, which we also use for a few other things on-site).
So MDN is a Python project with a couple JS utilities attached. And if you set up a local copy, you can pretty easily see that Python is by far the heaviest-used language. But due to the way GitHub counts and reports statistics, it shows up as a JavaScript project.
To pick on an easy example: the copy of jQuery we have in our repository weighs in at just over 9,000 lines. So just having jQuery means you need to write over 10k lines of code in order to get the "real" language of your project recognized.
"N.B. If you aren't authoring a package that is intended to be consumed by others (e.g., you're building a web app), you should always check installed packages into source control."
It felt wrong committing dependencies to the repo, which I agree with. I hate my diffs being drowned in external changes, I'd rather see that someone simply upgraded a dependency. Plus it does skew the project, both for what the primary language is, as well as how much a committer is contributing.
I would love to see this eventually in Bower! They have an issue for it [2].
[1] "Why not just check node_modules into git?" http://blog.nodejs.org/2012/02/27/managing-node-js-dependenc... [2] https://github.com/bower/bower/issues/505
But that's shouldn't put weight in either direction. Instead, there's a much deeper issue here: Ops should be building packages for deployment. Whatever that means, RPMs, VMs, Docker images, ... Just separate the concerns. Seal it up, and store it forever and ever, perfectly.
Because even if dependencies are there, safe and happy, most applications have a build process. Which takes time, and could be different on the machine it's building on. Only you can prevent production fires.
JavaScript, however, tends to require (or at the least follow the practice) of having a copy of your JS 3rd party dependencies in your repo.
So you may have 30,000 lines of python dependencies and 20,000 lines of JavaScript dependencies, but only the JS shows up in your project files to get counted.
This isn't even asking the question of if the new code in the project or the total enabling code is what should be counted. If we count total enabling code, do we count the Linux kernel implicitly too?
The files that get changed/updated are the ones that matter. If most of your diffs are PHP, then you're mostly workign with PHP.