Integration with (AMD) Package Manager

[micmath]

A few developers interested in the idea of a package manager (like npm) aimed at client-side JavaScript have recently started a discussion and plans around how to build such a tool.

Part of the design that we haven't yet worked out is the module meta data and the repo. I was happily surprised to see that you seem to have answered (possibly) that question for us!

Would you be interested in some discussion around how to ingrate a package manager tool into your repo?

see: https://github.com/micmath/ssm
and: http://groups.google.com/group/amdpackages-discuss

[ajpiano]

We are definitely interested in the discussion, having a CLI tool would be a big win! However, most jQuery plugins aren't developed with AMD, is that going to be a requirement for ssm? We've have also tossed around the idea of building our own package manager for handling plugin downloads, but it's only been conjecture so far. Since the outset of this process though, I've definitely hoped we could do something to facilitate this workflow.

[micmath]

AMD would not be required. We plan to have the option of integration with
build-time tools like r.js and almond (see James Burke), but that is only
an optional aspect. As long as your code-deliverable has a "package.json"
to describe it and is available from a URL (like github), then we can use
it. This seems to blend very nicely with your own requirements, as I
understand them.

On 9 December 2011 14:22, adam j. sontag <
reply@reply.github.com

wrote:

We are definitely interested in the discussion, having a CLI tool would be
a big win! However, most jQuery plugins aren't developed with AMD, is that
going to be a requirement for ssm? We've have also tossed around the idea
of building our own package manager for handling plugin downloads, but it's
only been conjecture so far. Since the outset of this process though, I've
definitely hoped we could do something to facilitate this workflow.

---

Reply to this email directly or view it on GitHub:
#3 (comment)

[scottgonzalez]

The WordPress site is going to track package.json as metadata for each plugin version post, so we'll be able to build an HTTP API on top of the WordPress database. That should be able to support anything the CLI tool needs. If you could list out what types of queries you'll need to run, we can build the API around that.

[micmath]

I've added this as a requirement in our github project.
see: https://github.com/micmath/ssm/issues/2

Can we discuss that API as a new issue on your github project?

2011/12/9 Scott Gonzlez <
reply@reply.github.com

The WordPress site is going to track package.json as metadata for each
plugin version post, so we'll be able to build an HTTP API on top of the
WordPress database. That should be able to support anything the CLI tool
needs. If you could list out what types of queries you'll need to run, we
can build the API around that.

---

Reply to this email directly or view it on GitHub:
#3 (comment)

[scottgonzalez]

Sure. Feel free to create a new issue to track the API.

[sbp]

The primary mode of operation for a jQuery plugin manager (jpm for short), I think, should be to let the user download only the files necessary within a plugin to make the plugin work.

At the moment, package.md has a single optional "files" field. I don't think that "files" alone will be enough to perform this primary task because it doesn't let the user choose between source and minified versions. I suggest instead, using the terminology on jquery.com, having optional "production" (for minified JavaScript), "development" (for source JavaScript), and "media" (for CSS, images, and other supporting files) fields. For most plugins, this means that all the authors will have to specify is:

"production": ["jquery.example.min.js"],
"development": ["jquery.example.js"]

Though optional, the pre-commit validator should warn strongly if a "production" field is not present, noting that the plugin will not be usable with the jpm if not present. If the jpm is available as soon as the site launches, it will help people to understand what the manifest fields are for, how they work, and why they're so important.

I suggest particular styles for the fields. All JavaScript files enumerated in the "production" manifest must end with ".min.js". All files in "development" must end with ".js" and not "min.js". On installation, it might be sensible to download everything by default to a namespaced directory, "./jquery-plugin-name/". This means that ["build/jquery.example.min.js"] would not be a good production value to use, because it would put the main script in "./jquery-plugin-name/build/". This could be stated in package.md. The biggest test of a jpm would be whether it can support jQuery UI bundling, with themes. A theme could be a jQuery plugin that only has a "media" field.

Other kinds of fields would also be possible. Sometimes versions of plugins that automatically perform certain operations are useful. For example, a version of masonry that automatically called $(".masonry").masonry() on $(document).ready() would be useful, assuming that the user always wants things to "just work". Such an option might necessitate a different manifest field and filename scheme, e.g. "auto" and .auto.js. Or the logic to automatically deploy a plugin could be put in a separate file, and the downloader could simply concatenate it to the end of whatever it installs if the user selects the automatic option.

[scottgonzalez]

@sbp Many developers don't include minified (and in the case of multi-file plugins, concatenated) versions inside their tags, so that's not even a consideration for something that should be strongly warned against.

[scottgonzalez]

It's been three months and we haven't gotten a set of requirements. The requirements will go into a new issue anyway, so I'm closing this.