Cleanups

[fitzgen]

A series of cleanups and follow ups to #205. See each commit for details.

r? @jlongster

[sokra]

I personally don't like that generated files (dist/) are commited into the repo.

[fitzgen]

I personally don't like that generated files (dist/) are commited into the repo.

Can you expand on why?

I agree that it isn't the most "clean" because they aren't part of the source, but instead artifacts created from the source. However, this enables people to just download a built version of the library without building themselves (#179) and uses .gitattributes to mark the files as binary so that it only displays whether they changed or not in diffs rather than dumping the duplicate/irrelevant changes out with the rest of the diff.

[sokra]

You'll get inconsitent PRs (some with generated files change, some without). PRs conflict more often because generated files differ (with binary files even it's even more likely).

If you want to offer a download to the generated file, you could keep the generated files in a gh-pages branch and use Continuous Delivery (i. e. Codeship) to build them automatically.

[jlongster]

fwiw, I keep the dist files in the nunjucks repo while it is nice, I do run into problems. Sometimes I forget to regenerate them, or I accept PRs but don't regenerate them and commit back, etc.

If there's a way to automatically build and push to gh-pages whenever a new commit lands to master, I'd say do that and just link directly to those JS files from the README. I'm not sure if you can do that without a complicated CI setup though, which may not be worth it for this project. If it's a simple webhook or something like that though, I think it's a good idea.

[jlongster]

Is the only reason for this so the github interface doesn't show it? I don't really think it's worth it; it would make conflicts harder to figure out, which is more likely with the dist files committed.

[fitzgen]

It makes git diff not spew changes for that file as well. I think it is worth it since the best way to handle conflicts in the generated files is to kill them and regenerate them.

[jlongster]

Oh looks like you're already using TravisCI. I definitely think we should generate builds from there and just link to them in the README.

[jlongster]

missing end quote

[jlongster]

r+, but I agree about using TravisCI to use builds. Can we look into that?

[fitzgen]

I think we could use http://docs.travis-ci.com/user/deployment/releases/ to have travis attach the build files on each release, but I'm not sure what the implications of attaching a token to a public repo are in this specific case (and so I am very hesitant).

[jlongster]

I know other projects do this somehow, even if it's just making the links for dist files straight from travis-ci.com. Might be worth asking another project at least (I can't actually think of one off-hand...). But it's not a big deal, though in my experience it does get annoying over time.