Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
AMD Consistency #211
This topic came up briefly in a previous AMD issue.
In AMD it's typical for a module to return a handle to the functionality it provides. It becomes a little less clear what to do when the module represents a plugin or there is a centralized namespace also receiving the functionality like with CanJS.
I think the important thing is to be consistent and CanJS is not quite so.
All of the core modules, i.e.
There may be other modules one could argue for a change in what is returned, but these were the ones that stood out to me.
In regards to
The latter seems more in line with what CanJS has already done.
I think these are good suggestions and will mark it for 1.2. The problem is, that when changing the module return value all the code referencing that module (AMD or Steal) needs to be changed. We also need a way of documenting the module return values.
Also, EJS and Mustache have to return then
People can overwrite the can module to require other things.
I don't think we should remove the global can:
We have a very large website.
Now for the little apps we use canjs 1.0.5. For a new module we are currently canjs 1.1.5 (the AMD-version).
The problem that we are having right now is that if I'm loading the topnav in the new module then the global can is being overridden with two versions of canjs.
No I was hoping that if I updated these little apps to an AMD version I could contain the version of canjs within the scope of that script. But if this isn't the case like mentioned above I have to rewrite these little apps so they can work without canjs because for future modules we want to use future code of canjs. But there isn't always the time to update the topnav to the new version and certainly is no time to update all old canjs-modules.
Because of this, I think it's better to remove can from the global scope.
I think GLOBALCAN is a good enough solution for now. If someone has problems with this, we can add can.noConflict() type thing that restores the original can.
I'm not sure why AMD would complain though ... as long as you are using the can passed to you, you should be fine.