Expand API to get access to dependencies or module

[alexander-alvarez]

Currently we can only get to the exports of the module resolved, not the actual module itself.

My use case is this:
I have a series of tests cases that test default export of a module, who's classes changes depending on environment variable -- the "classes changing depending on environment variable" was the easiest way I could integrate these two different solutions (temporarily)

In order to do this, I have to unsee the imported modules, so that the next time ember tries to resolve them, they will be reevaluated. One of my problems is that since (to my knowledge) I can't access the dependencies of the file, and addon files are reexported app -> addon, I can't programatically get to the underlying addon file to have it reexported.

// right now I hard code, which is fine since this is temporary
require.unsee('my-addon/serializer/user');
require.unsee('my-app/serializer/user');

// I feel as though I should be able to do something like
const module = resolver.findModule('serializer:user');
// unsee module and it's deps so they are re-evaluated even if the serializer comes from an addon.

Thoughts or ideas?

[alexander-alvarez]

@stefanpenner thoughts?

[rwjblue]

Based on a conversation with @krisselden, I believe that we should refactor things to essentially ref-count, so we can also unsee all modules which are no longer in use after unseeing the only module that depended on them. I believe that this would satisfy the issue you described above?

[alexander-alvarez]

I think this would work for most cases.

Not sure if it still holds up when inheritance is in the picture:

BaseComponent
ClassA extends BaseComponent
ClassB extends BaseComponent

// my-addon/addon/component/base.js
class Base {}
// my-addon/addon/component/class-a.js 
import Base from './base';
// my-addon/addon/component/class-b.js 
import Base from './base';

// re-exports
// my-addon/app/component/base.js
export { default } from 'my-addon/base'
// my-addon/app/component/class-a.js
export { default } from 'my-addon/components/class-a'
// my-addon/app/component/class-b.js
export { default } from 'my-addon/components/class-b'

If we didn't have the other classes extending from base, and we unsee my-addon/app/component/base.js then my-addon/addon/components/base would have only been used in one place and should be unseen (given the logic explained above).

However with other classes importing my-addon/addon/components/base, then there would still be other modules that depend on it.

[stefanpenner]

Based on a conversation with @krisselden, I believe that we should refactor things to essentially ref-count, so we can also unsee all modules which are no longer in use after unseeing the only module that depended on them. I believe that this would satisfy the issue you described above?

IMHO this to too much complexity to add.

If this is really needed, then in complex cases, why not just purge all modules that match some known prefix like <appname>?