Future of the Plugins site

[dmethvin]

This issue summarizes the private jquery-devs-list discussion started by @scottgonzalez regarding future direction of the plugins site.

Given the other priorities and limited resources of the Foundation, we haven't been investing in enhancements for the Plugins site over the past year, as evidenced by the open issues in this repo. Even with more resources, it isn't clear whether we should invest them here when there are other solutions such as Bower and npm that span the entire scope of dependencies, not just jQuery.

At this point if we were to point developers elsewhere, it seems the only two viable solutions are Bower and npm. The core team recently dropped Bower for npm in managing its own internal dependencies, and I think most of us would prefer to see npm improve so that it can be a good tool for client-side developers. Here are a few of the things mentioned in the thread that need to be addressed via code, documentation, improved practices, etc:

• Component users don’t like installing a full source tree and component authors don’t like keeping the ignore list up to date.
• Poor control over where components get installed
  • Deep npm deps cause errors on Windows; already a problem with lodash
• Reliant on the registry as a single point of failure
• Difficult to run different release channels (stable, testing, dev, canary)
• No namespacing of packages
• Having taken a ‘not opinionated’ stance, it is now difficult to enforce best practices that would help people automate things.
• Duplicate dependencies are acceptable on server, but a big problem on clients

Most points courtesy of @addyosmani

[seldo]

Thanks for summing these up and inviting us to the conversation! We have good answers for some of these, and less-good ones for others. Let me take them point by point:

1. ignore list maintenance: if you want to go with whitelisting instead of blacklist, you can use the files field of package.json. It lets you explicitly list a set of files and/or folders to be included ( see https://www.npmjs.org/doc/files/package.json.html ). Beyond that we'd have to do some work; tell us what this should look like.
2. deep deps on Windows is very much a concern of ours, and is being addressed by a much larger refactoring effort of the entire installation process; we blogged about that refactoring here: http://blog.npmjs.org/post/91303926460/npm-cli-roadmap-a-periodic-update and it specifically mentions window paths. We don't have a specific delivery date for this yet though. As for other "poor control" I think I need more detail; I am not familiar with how jQuery plugin installation works.
3. SPoF: npm registry uptime was 100% in July and we continue to invest in reliability and scaling. npm's core database is also easily replicated via couch or packages like https://www.npmjs.org/package/registry-static which don't require a lot of configuration (a fair amount of disk space, though). npm Inc also offers paid on-premises solutions but that's probably not appropriate for this use-case.
4. release channels: using npm's tag command ( https://www.npmjs.org/doc/cli/npm-tag.html ) you can set arbitrary tags like testing on any release, and npm install mypackage@testing will install the latest version in that channel. There are some ways we could make this a little smoother, I think (like promotion from one channel to the next). We'd be interested to get feedback on how to improve here.
5. namespacing: this is in progress. Support already exists in the npm 2.0.0 client (currently in alpha) and in the npm Enterprise private product; the plan is to roll this out to the public registry in Q4. A roadmap blog post about this is coming soon but you can see a basic description in the issue about the feature here: https://github.com/npm/npm/issues/5239
6. not opinionated: we continue to believe this is a feature, not a bug :-) We have an upcoming feature for www (a blog post about this is also due) called "ecosystems", but the TLDR is that they will be programmatically curated subsets of the registry. A hypothetical jQuery ecosystem could be maintained by the foundation which could check packages for best practices and either give them higher ranks in search as a result, which is nice way to incentivize best practices while improving search, or reject them from the ecosystem entirely (they could still be published to the registry, they just wouldn't turn up in the ecosystem-specific search). Look for more details about this on our blog later this week.
7. duplicate client dependencies: this is by far the hairiest problem when using npm on the client side. We have talked to the ember and angular folks about this as well. I've yet to hear a solution that doesn't re-introduce the dependency hell that npm is popular for (mostly) eliminating. This is where I'd be most eager in talking more about how it should work; a solution may lie in the refactoring of npm to make it more modular (discussed in the roadmap post I linked to earlier), which would allow client-specific packaging tooling to be written without excessively complicating npm itself.

I hope this helps! As I mentioned in email, npm is thrilled that jQuery is considering us as a package repository, and we are eager to make this work.

[dmethvin]

@seldo, apologies for leaving you hanging on this. We're having a team meeting tomorrow and had kind of put this on hold pending that meeting. We're also looking forward to figuring out how to make npm work as a front-end package manager.

[rnicholus]

It looks like the plugins site is already dead, as plugin updates and additions pushed over the last couple days have not appeared on the site. The latest plug-in update/addition was early October 8. Is this known to the team?

[scottgonzalez]

Yes, this is known.