We should avoid giant JSON files about browser-compat-data

[wbamberg]

Yes, we've talked about this and agreed that a build step seems like the best way to make things easier for contributors without making them harder for the macros.

As you say, actually building the things seems trivial. I'm more worried about where the build code is hosted and how we secure it. Even just where we are now, we're automatically building (parts of) hundreds of MDN pages from content that lives outside developer.mozilla.org. To the extent that we can trust access to this repo, that's OK, but are we further extending our trust by having a build step?

[JeremiePat]

My opinion here is that the build mechanism should be part of that repo as it will makes things easier to maintain in the short term. If we agree on #22, I would suggest the following organization:

Folder structure:

.src
.tools
.tools/hooks
.tools/scripts
data

.src will contain all the JSON files with our data that needs to be maintained

data will contain the built (aggregated, minified) JSON files ready to be used

.tools/scripts will contain all the necessary script (Node.js scripts) to make the build, run tests, etc.

.tools/hooks will contain git hooks necessary to enhance testing and build to make sure the whole data set remain coherent (at that point, as we are using Travis to automate testing, it is not a hard requirement, just some nice helpers).

On top of that, we can use NPM script to run everything is needed (at minimum I suggest npm test and npm run build)

Such organization will make things easier if it appears that maintaining the tool chain and the data in the same repo is not sustainable (but I doubt so at that stage)

[Elchi3]

WebExtension JSON files were the only ones with this problem. I'm calling this fixed.