add to npm

[calvinmetcalf]

it would be nice to be able to download curl via npm, though since the name is taken you'd either have to pick another one like cujo-curl or considering the one on their hasn't been updated in 2 years you could ask @ianjorgensen nicely if he was willing to give it up, if this curl had a major version 1 or greater it wouldn't even cause any conflict for the old curl version which is at version 0.1.4.

[unscriptable]

Hey @ianjorgensen, any chance this could happen?

Is your curl project still alive and well or could we possibly use the "curl" name on npm? We've had several dozens of requests to put our curl.js project on npm (as "curl") since that's how devs have used it since 2010, whether using bower or manually downloading it.

Thanks for your consideration!

Regards,

-- John

[mk-pmb]

Hi, I'd opt for cujo-curl in order to save me confusion with the curl that groks URLs. Yours, MK

[unscriptable]

Ok, so I gently reached out to @ianjorgensen. However, he seems like he's not going to relinquish the name "curl" on npm. He didn't even answer my most recent email, so that seems like a "no".

Here's the problem with having a different name on npm than on bower (and github): curl.js users can not mix node/npm/browserify code with projects that use bower to manage dependencies or projects that manually manage dependencies (i.e. via github tarballs).

// for npm and browserify
var textPlugin = require('cujo-curl/plugin/text');

// for bower or manual download
var textPlugin = require('curl/plugin/text');

At the moment, I can't think of any reason people would want to use curl's accessory modules (plugins, shims, or loader extensions) in node or browserify. All of these accessory modules are designed to help load things in browsers, which is meaningless in node and either redundant or convoluted in browserify. Therefore, I find it hard to believe you'd ever need the code above.

However, there are reason to use curl.js in node. Here are the reasons I can think of:

• to load pure AMD modules in node
• to allow package aliasing of node modules
• to use third-party plugins

All of these things can be done with only one call to curl.config(). So the code that is different in node would typically just be one line in one module: var curl = require('cujo-curl/dist/curl-for-ssjs/curl');

So maybe this is moot? Yes, it's annoying, but not devastating.

Any further feedback, folks?

-- John

[calvinmetcalf]

A couple ideas, I'd lean toward the second:

• in node have the plugins be accessibly by the curl object `require('whaterver-we-call-it').plugin.text
• publish them all to npm, curljs, curl-text, curl-commonjs etc no reason they can't be all separate packages even if they live in the same repo

[unscriptable]

Thanks @calvinmetcalf! Micro-packages is an interesting idea.

[unscriptable]

Done, finally! https://www.npmjs.org/package/curl-amd

[briancavalier]

Yay!

[sompylasar]

@unscriptable @briancavalier Sorry for being late but why the package is called curl-amd and not cujo-curl? It is really confusing with curl library that performs HTTP requests. I agree on that with @mk-pmb comment above ( https://github.com/cujojs/curl/issues/223#issuecomment-34417607 ). Please please please rename the package until people started using it.

[unscriptable]

@sompylasar: Hmmm... I thought curl-amd would also help differentiate curl.js from unix-curl-like packages? no?

[mk-pmb]

Sorry for my previous comment (deleted) mixing up the role of name parts. I think curl-amd would seem to be an AMD compatible version of the curl package, so I'd opt for curl-amd-loader if cujo-curl seems too similar to that other curl. Yours, MK

[sompylasar]

curl-amd looks like a somehow-AMD-specific version of cURL wrapper.

curl-amd-loader might be a better name.

Personally, I prefer cujo-curl because it minimizes the ambiguity.

If I were CujoJS author, I'd also prefer cujo-when, cujo-msgs, cujo-cram etc. because this highlights the identity of cujo set of libraries and saves them from any future name collisions. Just imagine someone would blindly call his module msgs (may stand for some imaginary Microsoft Grid Service which may appear in future).