Another registry for Javascript files and another json package description. This is getting ridiculous, you guys (npm, component, bower, volo, ender, jam and now plugins.jquery) should get together and fix this mess.
Would any of the CommonJS[1] "packages" specs be a good fit for them, or are they all too disparate? Is that even a concern of CommonJS?
It seems like JS could use some sort of working group to address these types of issues, such as PHP with the FIG[2] (Framework Interoperability Group); not sure if CommonJS is it, or could be...
I hope there will be less arguments of "...but standards are bad..." this time around.
JS community is maturing to the point where they do need to stop reinventing the wheel.
Occasionally there are developers who just love to write more code and churn stuffs out cuz you know.. that's what rockstars do :) (and make a name for themselves).
I whole heartedly agree. Yes, jQuery plugins is trying to be a curated field of "high quality" plugins but at the same time I can only concur with your frustration.
Python -> pip, Ruby -> gem, (more but I'm lazy.) These are good things. They make our lives so much better.
Javascript targets multiple domains, unlike other languages, so I understand the issue about consumer installers that build differently. But at least let's agree on a single json and on a single registry where everyone pulls from the same files so that we don't need to push our packages to 10 different registries and write 10 slightly different json descriptions for them.
What I hate, that most of the jQuery plugins have a huge lack of documentation. You select plugin and then spend next day trying to figure out how it's working. It's almost the same as dowloading random js file form random website and trying to use it. Looked through currently available repos, and half of them lack even simple plugin usage cases in repositories :)
That's why I like the component (http://github.com/component/component) approach; keeping things to such a minimum feature wise that you can understand very easily what each component does.
I love jQuery, but modules tend to be overdoing it on the configuration/options side. Keep things lean and orchestrate.
Component is really really great. It's the hero JavaScript package management needed. :)
When it's more mature its dom components will probably replace jQuery for me.
If you keep using plugins, you're probably going to want to understand how they work since you can't always rely on the person developing them. That said, I'm STOKED that this is finally back!
Interesting software stack running this registry: Wordpress on Apache/MySQL to serve the website and Node.js with SQLite to automatically add content using the Wordpress API.
https://github.com/jquery/plugins.jquery.com
Wordpress is good at serving essentially static content so that part seems reasonable. The jQuery team is good with JS so node makes sense for building backend services. The service itself is not complex and probably doesn't have huge scaling concerns. Essentially performs a git pull when triggered by a webhook.
Wordpress is good at serving static content? Web servers are good at serving static content. Wordpress is a huge, monolithic CMS with vulnerabilities appearing frequently, thus I would call it rather bad at serving essentially static content.
It would be nice if some of these plugins at least provided a decent demo. Even on their github page or something. Maybe jQuery should make that a requirement.
I'm having issues getting my plugins to display, even after adding the service hook, creating the package file and tagging it, it's been hours and yet nothing.
Sorry about the trouble - there are some errors in your manifest file that need to be corrected before it can push to the site successfully. We have been manually triaging invalid pushes and reporting the errors back to authors, as we're still in the process of rolling out better error-reporting to users. Thanks for bearing with us!
I had a similar issue so I posted a question in the #jquery-content IRC channel. They're looking in to it and recommended that I press the "Test Hook" button from the Webhook panel to get it to go through - and that worked. It sounds like the tags aren't being detected for some reason.
They had a plugin site running for a long time, but one of the admins accidentally deleted more than half of the database one day when trying to purge some spam, and the most recent backup was over a year old, so they decided to scrap the whole thing and move to a git-based system.
I'm pretty sure it used to exist, and then got taken down because it had too much crap on it. Looks like they've redesigned it, and are hoping that they'll get less crap this time around.
To register and publish your plugin, you’ll need to push your code to a public repository on GitHub, and add our post-recieve webhook URL (http://plugins.jquery.com/postreceive-hook) to your repository. The next time you push a semver tag, we’ll take care of registering the plugin name and updating its page on the site. When you’re ready to release the next version of your plugin, just tag and push again!
I'm curious how exactly they're doing this.
I created a similar site (but for all javascript plugins, not just jQuery), called http://jspkg.com. I built Github-import integration to add new projects from Github, and I wanted to do the same "automatically update when you push a new version tag" functionality, but Github doesn't fire the post-receive hook when you push tags, only when you push commits. It used to say that in the "When hooks are fired" section of the help page [1], but they've since updated that page to say almost nothing at all. I had also talked with a couple Github folks at the time, who confirmed this was the case, and that it'd cause problems for this exact use-case.
I started thinking of a few workarounds, but never settled on any of them, as none of them seemed like they'd work just right...
One workaround I thought of was to post to jspkg when the post-receive hook is fired, and allow jspkg to poll the git repo for the next couple minutes to see if it finds any new tags within that window. This seems like an ugly hack to me (not to mention, it would add a lot of unnecessary work on the server's end), and would still not be totally effective, if you waited longer than the window to push your new tags to github. I'm guessing it'd work fine the majority of the time, but as a developer, it wouldn't make my life that much easier if I still had to check jspkg.com every time just to make sure it worked.
So, then I started thinking of another option. Perhaps, instead of importing tags directly, maybe I have a post-receive hook that just looks to see if the package.json was modified, and if so, see if the version was bumped. And if it was, import that snapshot of the master branch. The issue with this is that you can't use the post-receive if you don't have a package.json (though maybe that's not entirely a bad thing). It also means that it might create snapshots when you don't expect. For example, if I change my package.json and then do a couple more commits and then tag the release, the distribution on jspkg will be from when the package.json was updated, not when the tag was created.
Another option I was considering is just writing a really simple git hook (not a github hook) that uses jspkg's restful api to upload a zip file from the users machine when they create a new version tag. Then it wouldn't rely on github even, but it would require the user to install the commit hook locally.
At any rate, I guess I'll have to check out the source code for the plugin registry to see what they settled on.
