I'm working on an open source Project written ins Javascript ES6. I use babel to transpile it to ES5. This way I have a folder structure like that:
/project
/src *raw ES6 files*
handler.es6.js
app.es6.js
/lib *transpiled files by babel*
handler.js
app.js
/dist *combined an minified files, ready to use*
project.min.js
I use grunt to transpile an minify the js files.
The only files that may be changed manually are in /src. The other files are generated automatically. So if a user makes a change to app.es6.js and sends a pull request without running the grunt task, the files in /src and /lib will be out of sync.
My question is, what is the best way to handle this build tasks in a GitHub project.I already looked into travis, which is already doing the test for me, but I'm not sure if travis should or can push code to the repo. After all might it be best, to not commit the build files, since they can be computed from the source anyways?
First of all, store transpilled code under version control is not a good idea at all.
Look how it is solved in the history project: https://github.com/rackt/history/blob/master/npm-scripts/postinstall.js
They have a postinstall script for NPM, which checks that module has not been built yet and builds it.
If you add this thing to your repo, your consumers will build module on-the-fly during install. Also, if you are going to publish this in NPM registry, do not forget to include built files to reduce installation time.