New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GlimmerWrapper: Resolve modules without a default export #189

Closed
mixonic opened this Issue May 30, 2017 · 2 comments

Comments

Projects
None yet
1 participant
@mixonic
Contributor

mixonic commented May 30, 2017

Currently the implementation of RequireJSRegistry only finds default exports.

We would like it to honor named exports. There are two cases where this matters.

Case 1: named exports. For example:

// src/ui/components/my-foo.js
import Ember from 'ember';

export const helper = Ember.Helper.helper(() => {
  // some helper logic
});

We expect the absolute module identifier of ui/components/my-foo/helper would resolve this helper.

Case 2: default exports without type in the name. For example:

// src/ui/components/my-foo.js
import Ember from 'ember';

export default Ember.Component();

We expect the absolute module identifier of ui/components/my-foo/component would resolve this helper.

@mixonic mixonic referenced this issue May 30, 2017

Closed

Module Unification Epic #6332

8 of 13 tasks complete
@mixonic

This comment has been minimized.

Contributor

mixonic commented Jun 2, 2017

Another way to put this is that the following lookup would occur for a specifier:

helper:/my-app/components/my-foo

my-app/src/ui/components/my-foo/helper w/ default
my-app/src/ui/components/my-foo w/ named helper
component:/my-app/components/my-foo

my-app/src/ui/components/my-foo/component w/ default
my-app/src/ui/components/my-foo w/ named component
my-app/src/ui/components/my-foo w/ default b/c defaultType

I don't actually this functionality is hard required to consider module unification support basically complete. Going to close this for now but I've bounced it off @rwjblue and @dgeb for feedback.

Closing for now.

@mixonic mixonic closed this Jun 2, 2017

@mixonic mixonic reopened this Jun 9, 2017

@mixonic

This comment has been minimized.

Contributor

mixonic commented Jun 9, 2017

Talked about this with @iezer. Case 2 above is used by the migrator, and we should support it. This can be done by considering the defaultType of a collection and trying to resolve without /type at the end of the requirejs module if the defaultType of the current collection is being resolved.

@iezer has a stab at this in the first commit of #183, but it doesn't consider defaultType.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment