Create official loader module API.

[rwjblue]

Provides an internal loader module with the following named exports:

• getIds - Returns an array containing the id's of all registered
  modules.
• has - Returns true or false if a given module exists.
• define - Defines a new module.
• require - Requires a module (optionally relative to the current module).
• resolve - Returns the expanded module name given a relative path.

Closes #82.

[stefanpenner]

how does this differ from import require from 'require'; require and require.has? Is this just that + more API?

[rwjblue]

@stefanpenner - require and require.has are basically the same, the other methods do not have public API's today. Also, I think import { has, require } from 'loader' is better 😝 ...

[rwjblue]

IMHO, we should probably eventually deprecate import require from 'require' (unless that is a standard part of the AMD spec?), in favor of import { require } from 'loader';. Since the latter case is quite a bit easier to track down who provides it.

I'm not suggesting any deprecations just yet, just pondering....

[rwjblue]

Also added some documentation for the new API.

[trentmwillis]

Overall this seems good to me, just one comment about naming (not super important).

[trentmwillis]

May just be me, but for some reason, I do not think id when I think of the identifier for a module. Usually path or name instead. When I first saw getIds() I had no idea what information it was actually returning.

[krisselden]

this is the unique id, usually name is relative or not where as this is registry specific.

https://whatwg.github.io/loader/#loader-import if you look here name is used for APIs like import() but the registry uses keys.

Would getKeys() be ok with you?

I hate naming things.

[rwjblue]

Where are we on this? I believe that all of the comments here have been addressed. What other blockers are there?

[rwjblue]

@stefanpenner / @krisselden - Are y'all ok with this? Any changes needed?

[stefanpenner]

I'm not terribly thrilled to:

• take over the loader entry
• duplicate/behavior API's that already exist on require

Is there a reason we can't just add more things to require?

[rwjblue]

I'm not terribly thrilled to:

• take over the loader entry

We can handle folks overriding via define('loader', so that their loader module wins but with a deprecation.

• duplicate/behavior API's that already exist on require

I'm happy to deprecate require here as well.

Is there a reason we can't just add more things to require?

A couple things that pop out at me:

• using the require module for things like define or define.alias which are completely unrelated to requiring things is pretty weird
• this packages name is loader.js, using require as our primary module API is bizarre and non-intuitive.

[stefanpenner]

I'm happy to deprecate require here as well.

I don't think we can, as require is a legitimate import AMD import, and in AMD land is already used to signal capabilities and other things.

I still feel we should just expand the API on require and not introduce a different thing.

[Turbo87]

closing due to inactivity