Reconsider :common set

Cc: @Sannis, @sourrust

Hi guys,

I’ve had a few ideas about updating the :common set of languages to better match reality and expectations.

Here’s the download stats from the site, by language:

 824 xml
 817 javascript
 776 json
 773 css
 690 sql
 680 php
 673 http
 657 markdown
 642 java
 638 bash
 611 python
 601 cpp
 592 apache
 587 diff
 587 cs
 585 ini
 582 ruby
 572 makefile
 571 coffeescript
 567 nginx
 561 objectivec
 556 perl
 551 dts
 131 yaml
 131 go
 100 swift
  96 less
  92 scss
  85 lua
< 80 — not interesting

The 500+ top are the current :common set (with “dts” being there by mistake, we’ve missed it during review).

I’ve got two alternative ideas:

• Drop the least used languages: coffeescript, objectivec, nginx, perl — and add in a few of the contenders: yaml, go, swift. This will freshen it up and leave it about the same size of ~40K.
• Extend the set considerably to include most non-niche languages. It’ll probably move it into ~200K territory (uncompressed) but the Internet has changed considerably, and may be it’s not that big of a deal these days. I could probably run a quick poll about it on Twitter.

What do you think?

[derhuerst]

@derhuerst the NPM build already includes all the languages, there’s no point in packaging them individually.

There is, for example in reducing the bundle size when using browserify, which seems to be the standard frontend workflow nowadays. It would also help keeping major version bump down to a minimum in the core.

Moving the core detection into a separate module would also be nice, as many non-browser tools could directly use it (see #1086).

[derhuerst]

Please introduce a new major version and create standalone definitions for almost all languages. 📦 🎉