Cleanup entries API

[krisselden]

Use a interface instead of exposing the entries pojo and migrate the ember-cli resolver to them to allow for alternate implementations of testing a module's presence or scanning modules.

[rwjblue]

The resolver itself uses an interface (see here) for this. FWIW, that interface combined with an override in the resolver makes testing various module registry combinations a breeze...

[rwjblue]

API's needed:

• has
• require
• unsee
• moduleIds
• eachModuleId

[stefanpenner]

We can deprecate requirejs.entries and move to something else that provides this sort of API.

[rwjblue]

I was thinking of implementing this similarly to how you implemented require in Ember itself.

import has from 'loader/has';
import require from 'loader/require';
import getModuleIds from 'loader/get-module-ids';
import eachModuleId from 'loader/each-module-id';
import {
  has,
  require,
  getModuleIds,
  eachModuleId
} from 'loader';

Then we can deprecate .entries, thoughts?

[krisselden]

Can those just be loader? And we need to keep require for commonjs wrapping

[stefanpenner]

Can those just be loader? And we need to keep require for commonjs wrapping

import { has } from 'loader'
import require from 'require';

?

[rwjblue]

@krisselden - I do not understand what you mean. Can you jot down your proposal in terms of import statements?

[rwjblue]

I see, we need import require from 'require'; so that we can give a special require per module (so they can do relative requires).

[stefanpenner]

I see, we need import require from 'require'; so that we can give a special require per module (so they can do relative requires).

we already have this one, but loader/require seems legit.

[rwjblue]

👍

[rwjblue]

I believe the easiest thing to do would be to just add the define calls that we want in .clear here. This works for all except require itself, and that needs to be similar to this.

[rwjblue]

OK, discussed in person with @krisselden, and I think we are settling on the following API:

import {
  has,
  getIds,
  define,
  require,
  resolve
} from 'loader';

If there are no objections to the above, I'll try to get this going soon...

[kratiahuja]

How about alias?

[rwjblue]

The current alias API is odd, I was thinking we could land the API above (which does expose some version of alias via define.alias) and then submit a separate PR for making alias accept a second arg (for target).

[kratiahuja]

Sounds perfect to me!