Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

AMD support for runtime.js #634

Closed
phated opened this Issue · 12 comments

7 participants

@phated

I am currently using https://github.com/wearefractal/jaded to compile my jade templates to AMD, but have to use a custom runtime.js to keep jade from being globally defined.

Would it be possible to add that functionality into the main project?

Thanks

@tj
Owner
tj commented

meh -1 from me, im not a fan of AMD

@monteslu

+1 from me. I love AMD. Is there any real downside to adding this?

@tj
Owner
tj commented

im fine with it if it can be a separate compile step thing, forget what the AMD signature looks like for registering

@phated

It just needs to be wrapped like so:

define([], function(){
var exports = {};
// Augment exports here
return exports;
});

I issued a pull request but if you don't like my naming or whatever, it would just be cool to have this. Thanks.

@tj
Owner
tj commented

I kinda feel like all these require type things are approached wrong. Everything should be module.exports / exports, and then the web "framework" or whatever build-system should wrap accordingly, there's a lot of fragmentation and inconsistency in the community right now

@monteslu

There's really only two formats with any mindshare right now, AMD and CommonJS. Both are useful, and are only somewhat competing. CommonJS is more typical on the server while AMD is more typical on the client. AMD is supported by jQuery, Dojo, Mootools, Firebug, and other things.

The pull request doesn't harm the project at all, and adds something very useful for client side MV*.

@evdb

To solve this issue for myself I've created jade-amd: https://github.com/mysociety/node-jade-amd

It has a cli that wraps the runtime.js and compiled templates in AMD semantics and is intended to play well with the RequireJS build process. There is an example app that exercises all the features.

Perhaps the way to close this ticket is to add some docs to Jade that points to other solutions like jaded and jade-amd. I tend to agree that it is a build process task.

@phated

I understand that there are ways to work around this with custom solutions (such is my solution - https://github.com/phated/grunt-jade), but I figured this would be helpful to keep upstream since runtime.js is a client-side file, and AMD is pretty much the standard for client-side modules right now.

@contra

@evdb - Wrote something similar (https://github.com/wearefractal/jaded). Would be nice if this was supported out of the box but using a 3rd party CLI/runtime isn't too bad.

@monteslu

So if at least three different projects are having to wrap the jade runtime in AMD themselves, why not just fix it upstream?

@ryanflorence

runtime.js doesn't need to be wrapped, RequireJS 2.0 has the "shim" config that works perfectly with the global pattern:

paths: {
  jade: '../node_modules/jade/runtime'
},
shim: {
  jade: {
    exports: 'jade'
  }
}

And you're done. If you're one of the few people who actually MUST remove the global variable then yeah, runtime.js should implement a noConflict (and while you're at it remove the built-in shims :\ ...) and then you can change the exports config on jade like so:

exports: function() {
  return jade.noConflict()
}

It's still RequireJS's responsibility to be the adapter.

@ForbesLindesay

AMD should just be built on top of a common-js version. And should be done so by people who use AMD, not in the library itself.

@rayjanwilson rayjanwilson referenced this issue in arctic-fire-development/dapper-gcs
Closed

app doesn't render in branch "upgrade-grunt-stuff" #17

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.