AMD Plugin Interface about core HOT 9 CLOSED

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?

from core.

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?)

from core.

Well it appears it exists partially in core/load. I suspect we just need to move some/all of these interfaces somewhere else and dojo/has should implement them.

from core.

load is missing a Normalize interface though.

from core.

Isn't that just an interface for AMD's require as called by consumers, and not specifically for plugins?

from core.

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?

from core.

I wonder if, like lib.d.ts or node.d.ts, there needs to be an amd.d.ts that can be shared by projects that will work with any AMD loader.

from core.

Currently, dojo-core has an incomplete AMDRequire interface defined in load.ts. There is a more complete interface defined in dojo/loader, so should we use that (PR)? Or should we extricate AMD definitions into amd.d.ts? Where would amd.d.t.s live (what project)?

from core.

We can close this issue for now and revisit if needed.

from core.