-
Notifications
You must be signed in to change notification settings - Fork 58
AMD Plugin Interface #59
Comments
I would think definitions for this would belong in dojo/loader, except if we still have any thought of being able to interoperate with other loaders, in which case adding an unconditional dependency on a loader you might not use would seem undesirable, and core would be the next best place since most other packages are likely to depend on that. @edhager, @bryanforbes, thoughts? |
Also, would this idea actually work for modules, especially in cases where we're exporting individual functions? (i.e. is it even feasible to say that a module's exports collectively implement an interface?) |
Well it appears it exists partially in core/load. I suspect we just need to move some/all of these interfaces somewhere else and |
|
Isn't that just an interface for AMD's |
DOH! You are correct, though I did find it in dojo/loader though. It seems the whole thing is already there, but I know we were trying to avoid a hard dependency on the loader. Is it better located somewhere else? |
I wonder if, like |
Currently, |
We can close this issue for now and revisit if needed. |
Shouldn't we put the AMD plugin interface as a specified interface either in core, or dojo/loader?
I noticed that in the core/has implementation, it isn't relying upon an interface, therefore potentially exposing an API that isn't consistent. One of the strengths of TypeScript is being able to collate these interfaces and expose them to others.
The text was updated successfully, but these errors were encountered: