curl in nodeJS

[Derick D]

I'm trying to use some of the same wire specs on both server and client.

I found that relative module paths in specs don't work without curl or a non-standard function to resolve paths as explained in this topic:
https://groups.google.com/forum/#!topic/cujojs/FB5IN9iT100

Client and server see very different paths to the same file, so using absolute paths in specs seems impossible.

I noticed curl 0.7.4 included "bug fixes for running curl.js inside node.js." so I decided to try using curl under node.

My attempt led to the following error:

curl.js:681
            var el = doc.createElement('script');
TypeError: Cannot call method 'createElement' of undefined

...which looks very browser-centric.


Is curl under node possible yet or is it in the plans for future versions?

[John Hann]

Hey Derick, 

In order to use curl inside node, you must require the curl/shim/ssjs module: 

var curl = require('../../path/to/curl');

require(''../../path/to/curl/shim/ssjs');

curl('app/wire-spec');

This shim module overrides the browser-specific bits. 

Alternatively, you can use the pre-shimmed version in the dist folder:

var curl = require('../../path/to/curl/dist/curl-for-ssjs/curl');

curl('app/wire-spec');

Not many people outside of the cujojs team use curl.js inside node (afaik!). We'd love some feedback. 

One of the issues imho is that curl isn't available on npm. Somebody else grabbed the name before us. We've been thinking of publishing the ssjs version under cujojs-curl or node-curl (or something else "namespaced"). 

This would allow you to `npm install` it and them write code like this:

var curl = require('cujojs-curl');

curl('app/wire-spec');

But then you'd have different versions of curl for front end and back end code. Thoughts?

Regarding relative paths:

Relative paths are somewhat problematic in AMD and CommonJS atm since the specs don't allow a module (i.e. wire) to normalize module ids on behalf of another module (i.e. a spec). We could devise a proprietary solution that only works in node and curl.js, but proprietary solutions make us sad. ;)  We would love to hear your thoughts on this, too. 

It's interesting that you say that absolute paths are impossible. In my experience, amd is flexible enough to accommodate node's overly-opinionated file structure. However, it can get pretty ugly with all of the "node_modules/" paths in your package config. :(  Again, would love to hear your thoughts since we would love for more people to share client and server code! 

Thanks!

-- John

Sent from planet earth

--
You received this message because you are subscribed to the Google Groups "cujojs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cujojs+un...@googlegroups.com.
To post to this group, send email to cuj...@googlegroups.com.
Visit this group at http://groups.google.com/group/cujojs.
To view this discussion on the web visit https://groups.google.com/d/msgid/cujojs/3e753e9d-3ad8-407f-992e-47843a12298c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Derick D]

The pre-shimmed version works like a charm!  Thanks!

I ran into a few difficulties in my travels...

var curl = require('./public/components/curl/src/curl/shim/ssjs.js');
console.log(curl);

echos

{}

var foo = require('./public/components/curl/dist/curl-for-ssjs/curl');
console.log(curl, foo)

echos

{ [Function: _curl] version: '0.7.4', config: [Function: _config] } {}

require('./public/components/curl/src/curl');
require('./public/components/curl/src/curl/shim/ssjs.js');
curl('app/wire-spec');

echos

./public/components/curl/src/curl.js:681

            var el = doc.createElement('script');

                         ^

TypeError: Cannot call method 'createElement' of undefined

One of the issues imho is that curl isn't available on npm. Somebody else grabbed the name before us.

When I was trying to install via npm I installed ian's curl, then finding that not to be the droid I was looking for, cursed his name and searched for 'cujo'.
Finding 'cujo' and Thinking maybe it was the entire unframework kit and kaboodle I tried installing it.

npm install cujo
npm http GET https://registry.npmjs.org/cujo
npm http 304 https://registry.npmjs.org/cujo
npm WARN package.json cujo@0.1.0 No repository field.
npm WARN package.json cujo@0.1.0 'repositories' (plural) Not supported.
npm WARN package.json Please pick one as the 'repository' field
cujo@0.1.0 node_modules/cujo

A preshimmed 'cujojs-curl' sounds great to me, I imagine most people developing will wish to keep the latest versions of curl on both client and server.  Do you think there will be many future changes that would deprecate enough of 0.7.4 to cause version incompatibilities?

Relative paths are somewhat problematic in AMD and CommonJS atm since the specs don't allow a module (i.e. wire) to normalize module ids on behalf of another module (i.e. a spec). We could devise a proprietary solution that only works in node and curl.js, but proprietary solutions make us sad. ;)

No idea what to do and I agree proprietary is no good.  What is the argument against allowing external modules to normalize paths?  I can't think of any malicious things that couldn't be done via shimming, though I'm quite new to AMD and contemporary javascript in general so am probably without useful insight on this topic.

It's interesting that you say that absolute paths are impossible. In my experience, amd is flexible enough to accommodate node's overly-opinionated file structure. However, it can get pretty ugly with all of the "node_modules/" paths in your package config. :(  Again, would love to hear your thoughts since we would love for more people to share client and server code!

I really should have appended that statement with 'AFAIK'.  I have much to learn.

[unscriptable]

On Wednesday, July 10, 2013 2:31:12 AM UTC-4, Derick D wrote:

The pre-shimmed version works like a charm!  Thanks!

Cool!

 

I ran into a few difficulties in my travels...

var curl = require('./public/components/curl/src/curl/shim/ssjs.js');
console.log(curl);

echos

{}

That doesn't surprise me since I know curl/shim/ssjs doesn't expose any of it's own functionality.  However, I guess that is kinda unexpected if you don't already know that. :)

 

var foo = require('./public/components/curl/dist/curl-for-ssjs/curl');
console.log(curl, foo)

echos

{ [Function: _curl] version: '0.7.4', config: [Function: _config] } {}

Yes.  This should be fixed.  The dev08 branch (a totally experimental branch, btw) exports the curl global so foo === curl.

 

require('./public/components/curl/src/curl');
require('./public/components/curl/src/curl/shim/ssjs.js');
curl('app/wire-spec');

echos

./public/components/curl/src/curl.js:681
            var el = doc.createElement('script');
                         ^
TypeError: Cannot call method 'createElement' of undefined

This seems like a bug.  

 

One of the issues imho is that curl isn't available on npm. Somebody else grabbed the name before us.

When I was trying to install via npm I installed ian's curl, then finding that not to be the droid I was looking for, cursed his name and searched for 'cujo'.
Finding 'cujo' and Thinking maybe it was the entire unframework kit and kaboodle I tried installing it.

npm install cujo
npm http GET https://registry.npmjs.org/cujo
npm http 304 https://registry.npmjs.org/cujo
npm WARN package.json cujo@0.1.0 No repository field.
npm WARN package.json cujo@0.1.0 'repositories' (plural) Not supported.
npm WARN package.json Please pick one as the 'repository' field
cujo@0.1.0 node_modules/cujo

We're still trying to decide what to put here.  Perhaps a cujo app generation tool using yeoman and grunt?  

 

A preshimmed 'cujojs-curl' sounds great to me, I imagine most people developing will wish to keep the latest versions of curl on both client and server.  Do you think there will be many future changes that would deprecate enough of 0.7.4 to cause version incompatibilities?

Heh.  Funny you should ask.  The direction of curl.js is being debated.  It seems we'll likely take it in a whole new direction.  We're leaning strongly towards it becoming an ES6 Module Loader shim with an accompanying toolkit for loading AMD, CJSM, and other things.  This would allow you to write forward-compatible code today.  

That said, it would probably be easy to provide a wrapper that mimics most -- if not all -- of the current 0.7.x functionality.

 

Relative paths are somewhat problematic in AMD and CommonJS atm since the specs don't allow a module (i.e. wire) to normalize module ids on behalf of another module (i.e. a spec). We could devise a proprietary solution that only works in node and curl.js, but proprietary solutions make us sad. ;)

No idea what to do and I agree proprietary is no good.  What is the argument against allowing external modules to normalize paths?  I can't think of any malicious things that couldn't be done via shimming, though I'm quite new to AMD and contemporary javascript in general so am probably without useful insight on this topic.

FWIW, we're now working on a solution within wire.js itself.  The normalization step performed by AMD and CJS environments is universal afaict.  Therefore, wire.js can implement it's own on behalf of the environment.  This shouldn't interfere with the rest of the module loading pipeline, but we'll likely create an API for devs to plug in their own normalization function just in case.

 

It's interesting that you say that absolute paths are impossible. In my experience, amd is flexible enough to accommodate node's overly-opinionated file structure. However, it can get pretty ugly with all of the "node_modules/" paths in your package config. :(  Again, would love to hear your thoughts since we would love for more people to share client and server code!

I really should have appended that statement with 'AFAIK'.  I have much to learn.

yes, padawan. as do we all. :)

-- John