Closed doomedramen closed 9 years ago
Thanks very much for taking this on.
However, is it really necessary to check the compiled dalliance-all.js and worker-all.js files into Github? These are big, probably won't diff well because they're generated by Closure Compiler rather than a human, and will change frequently, so will generate an awful lot of cruft when you do a new checkout from Github.
I also fear we'll get a pretty-much-random collection of versions committed, not just the releases. Anything that avoids this while keeping the build/* assets on Github will add a lot of friction to the development process.
Is there a way we can upload these assets, just for release versions, to the Bower repository?
Okay, after a fair bit of reading I think I now finally understand the differences between NPM and Bower (!).
There is extensive discussion of this kind of issue at https://github.com/bower/bower/issues/249
One approach to Bower-ization might be to rely on post-install hooks to compile the package after installation. In principle, I quite like this. However, it seems that you can't configure such a hook on a per-package basis (see near the bottom of the linked Bower issue).
Another approach might be to have another git repository for compiled versions of Dalliance and manually (or with the help of some scripts) push new versions there. I have a nasty feeling that this is actually what the Bower community would consider to be the "right thing".
Bower file added; /build compiled via gulp and taken out of .gitignore; .gitignore changed to use / for folder names; added ignore of json + jszlib to .gitignore, these seem to be created as part of the build process but I believe all js code is bundled into dalliance-all;
The bower file could have many more ignore rules to just keep /build (and I assume the img + css folders are still needed?).