Testing? CI?

[egeerardyn]

Probable, we should set up some testing to avoid obvious errors such as malformed XML/JSON/YAML files.

This would be possible using https://github.com/idleberg/sublimetext-gruntfile.js which offers an approach that is well-suited for Travis CI such that this is basically an "import and forget" kind of feature.

What do you guys think?

[bmcminn]

The only thing I would add is grunt-contrib-compress to package everything into a proper .sublime-package for quickly iterating against ST. Otherwise I think it should work just fine :)

[egeerardyn]

@bmcminn I don't fully understand (I'm not really familiar with grunt, AFAIK it's just a build tool).

I think we can surely incorporate rules to make the packages, but I'm really against storing generated stuff in a repo (it tends to make merges a pain).
So it's not really something that seems relevant to me for continuous testing as far as I see. But I agree that they provide good value for quick development cycles locally (or just having an easy way to install from source).

[bmcminn]

We would use .gitignore to remove generated packages from the repo. The idea for packaging the theme assets is we could very easily make this into a dev utility that automagically deploys the package updates into our local ST application folders. I have some ideas around tooling for this, but I could see this being an automation measure for local development and testing of features.

[ntwb]

I like this idea of Travis CI testing 👍

[egeerardyn]

After #9, perhaps it's also something we could incorporate into a build script: generation of the TOC.

[bmcminn]

@egeerardyn I've actually got a script that does this already, I'd just have to pluck the component out and incorporate it.