Closed EvanCarroll closed 9 years ago
This is one of the opinionated things about Bower that drives me nuts.
The only versions of Prototype that are safe to use are the ones associated with Git tags. Those releases, of course, are available publicly over HTTP: http://ajax.googleapis.com/ajax/libs/prototype/1.7.2.0/prototype.js
, or substitute the version number for older versions.
So I don't understand why Bower insists on a Git repo. If it needed the repo because it wanted to do its own build, I'd understand that. But it assumes that the code exists in already-built form somewhere in the repo. This despite the fact that HTTP is a great way to transfer text files, based on many years of evidence.
I don't like the burden on contributors that they remember to do rake dist
before they submit a PR, and I don't like the burden on me that I need to look at two different diffs (the source files and the new dist/prototype.js
) to make sure those diffs are identical.
In my rage, I hit submit too early. Anyway: I have philosophical disagreements with Bower. If they supported other means of fetching built source, I'd be on board.
@savetheclocktower would it be bad to have https://github.com/prototypejs/prototype changed to only be a public release repo that is updated during a normal public releases? Bower could point to that repo
A little scripting and some webhooks would make the most recent github tagged release on https://github.com/sstephenson/prototype available at https://github.com/prototypejs/prototype
I understand you have a different point of view about distribution, but making the public releases more accessible helps everyone.
I would be willing to manage it if you don't want to
Well, for one, a bower package isn't a mere Javascript file. It has to include a bower.json file that has it's dependencies. And, it's likely to include other "suggested" files in the future: perhaps a more sophisticated method of documentation retrieval?
Point being, keeping the compiled files in the repo isn't a bad idea and it makes your version authoritative and SHA-1 secure.. Unlike Google's CDN.
Well, for one, a bower package isn't a mere Javascript file. It has to include a bower.json file that has it's dependencies. And, it's likely to include other "suggested" files in the future: perhaps a more sophisticated method of documentation retrieval?
I wouldn't mind having a bower.json
file in the repo. I mean, I would mind, but it would be less offensive to me. And if bower.json
could point to the URL of the built file, and have a SHA-1 for verification, then I'd be on board with this.
But for the reasons I mentioned above, I'm not willing to go through the hassle of either (a) making contributors rebuild the distributable every time they commit, or (b) fixing the PRs of contributors who don't follow this step. I know that lots of JS projects have internalized this annoyance, but it still bugs the crap out of me.
@jwestbrook, if you'd like to investigate how we can automate this, I'm fine with that.
If prototype was compiled in ./dist, it'd be a lot easier to get it to work with a repo manager like
bower
. No one wants to install ruby to get basic prototype.js functionality.Most projects now put a compiled and a minified
.min.js
files into./dist