Publish to npm

[domenic]

We're pulling this down with "text": "requirejs/text" in our package.json, but that's rather suboptimal.

[jrburke]

Neat, looks like you are using the github support that was recently introduced in npm?

Can you expand on why it is suboptimal? I find using npm for browser code suboptimal:

• naming conflicts. This text plugin in particular would be awkward, even if just restricted to the domain of browser code.
• the ID-to-path lookups implied by node's IO lookup algorithm and npm's installation pattern are hard to work with in browser code, particularly when not forcing a build.

I was hoping the github ID support in npm would be enough to work around at least the npm registry naming issue, but I expect I would appreciate your perspective on it.

[domenic]

We get our browser code almost exclusively through npm.

• The naming conflicts are a nonissue for us; whether it's called "requirejs-text" or "text" or "asdf" doesn't matter to us. As long as there's a single registry wherein all the packages are stored, we can download them locally without fear of name conflicts. Whether that registry is GitHub and the names happen to have slashes in the middle, or npm and there's no such slash restriction, is immaterial.
• The ID-to-path algorithm of Node is perfect for building browser code, because it gives automatic deduplication. E.g. if app depends on widgetA and backbone, but widgetA depends on backbone, npm gives a directory structure wherein there is only one backbone folder, in app/node_modules/backbone, with Node's algorithm meaning this is resolved correctly for both app and widgetA.

As for why it's suboptimal to use the GitHub support, honestly, that's npm's fault. In particular you don't get semver support (isaacs/npm#3014), and there's a bug where it doesn't cache the repo (isaacs/npm#2482). If those were fixed we could just use npm against GitHub and all would be well.

[edef1c]

I should note that user/repo deps use the GitHub-provided tar.gz as opposed to using git. That's a lot faster than doing a git clone and getting rid of the history.

[jrburke]

As @nathan7 mentions, the github support should use some sort of archive provided by github instead of a full git clone, and it sounds like exact version matches work for the npm github support (just semver missing), so it seems like npm's github ID support is fairly usable.

On npm naming restrictions: it would be better if a project could choose a local name for the install, something like:

{
  "dependencies": {
    "text": "requirejs-text@~2"
  }
}

That would help a bit, then in local code, I could just refer to it as "text". In general, forcing global unique names for projects that have their own local conventions and naming is a design wart.

Example: for me to publish this now on npm, I would need to update the package.json's name file to be "requirejs-text". I find that distasteful. "npm": {"name" : ""} would be better, to indicate that this is for registering in that particular repo namespace. Global names suck.

On ID-to-path resolution: deduping is not my criticism (that is workable), but more the nested cases, and the insistence on packages/directories with "main" values. This makes it difficult to use without doing either some "on-install" or build step to generate a config to be able to use those in a front end project. It also means that you are mandated to have some ugly config block in the code, unless always building everything into one JS file. Support for a basic ID-to-path convention friendly to front end code and single file dependencies would be much better. More details here.

Some of the above is a bit off-topic, but feeds into my reluctance to encourage the npm registry for front end code. And listing some of it out now makes me feel cranky so I am not in the mood for doing this at this time. Particularly since the github ID support in npm seems pretty usable, even if you are locked to a particular version for the moment.

GitHub ID support in npm in general is the right way to go, so I would like to give that more time to see if the npm folks can get that fully baked. If not, then maybe this can be revisited later. But closing for now. I apologize if this causes some (hopefully) short term trouble.

[edef1c]

@jrburke I implemented this recently. It's in npm. Watch the logs when you install a GitHub repo. (if it uses git, upgrade your npm)

[jrburke]

@nathan7 ah ok, sorry I misunderstood at first. Great to hear!