Skip to content
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

Filter npm module defintions from catalogEntriesByType #162

Closed
wants to merge 1 commit into from

Conversation

ryanlabouve
Copy link

I created this PR to help explain the issue I reported here: #161

I understand that this may not the the desired solution. However if this is useful, or if there's some other direction I can take to help solve this problem, I'm happy to do so. Just let me know :)

Don't return things from catalogEntriesByType that don't belong to your main app.
@nathanhammond
Copy link
Contributor

This is not a viable fix, unfortunately. The current implementation pulls in everything from require.entries which has ${type}s/ anywhere in the path. It's likely that people are depending upon this behavior (whether or not that's a good thing). Different places I would look to fix this:

  • Prevent data_adapter from eagerly looking up all models (which means that it will be available in a broken format, but never passed to lookupFactory.
  • Have ember-browserify rewrite the module name at build time.
  • ???

Unfortunately both of those are hard.

Copy link
Contributor

@nathanhammond nathanhammond left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had these comments before I thought through the rest of the consequences.


test('Ignores browserify modules', function(assert) {
assert.expect(1);
def('npm:cool/model/package');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test will never fail. model needs to be pluralized.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Confirm on this one. Should be models here...


test('Ignores modules that are not part of the main app', function(assert) {
assert.expect(1);
def('liquid/awesome/model');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pluralize, add trailing slash.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nathanhammond - This particular module stub is emulating "pod models" (your favorite 😉 ), and singular form is correct here.

@igorT
Copy link

igorT commented Jan 14, 2017

@nathanhammond do you have an example for where this fix fails? We originally filtered out things starting with npm but @rwjblue suggested we should filter out other spurious matches. dataAdapter is definitely the wrong place to fix this, because the method called catalogEntriesByType shouldn't be returning modules which don't match the type.

@nathanhammond
Copy link
Contributor

nathanhammond commented Jan 14, 2017

@igorT Given this if you have an addon which defines a model which ended up at some-addon/models/foo then this change would break it as the foo model would have previously been available.

Forcing everything to be in the application namespace is too heavy-handed. (Note: I prefer this change, but I don't believe that we can reasonably make it except as part of something like this: emberjs/rfcs#170)

@rwjblue
Copy link
Member

rwjblue commented Feb 27, 2017

Forcing everything to be in the application namespace is too heavy-handed.

FWIW, this is untrue. Models that are not in the applications namespace can never be resolved anyways (since we only resolve things in the apps namespace).

Copy link
Member

@rwjblue rwjblue left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think one smallish tweak needed to the test here, but otherwise this should be good to go...


test('Ignores modules that are not part of the main app', function(assert) {
assert.expect(1);
def('liquid/awesome/model');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nathanhammond - This particular module stub is emulating "pod models" (your favorite 😉 ), and singular form is correct here.


test('Ignores browserify modules', function(assert) {
assert.expect(1);
def('npm:cool/model/package');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Confirm on this one. Should be models here...

@stefanpenner
Copy link
Contributor

stefanpenner commented Mar 10, 2017

@rwjblue / @ryanlabouve / @nathanhammond

This is on the right track or... (above conversation was a tad confusing)

@ryanlabouve do you have any cycles to address @rwjblue concerns? That way we can move this forward.

@ryanlabouve
Copy link
Author

Sure thing! Sorry for delay. Will do it tonight.

@rwjblue
Copy link
Member

rwjblue commented Mar 10, 2017

Yep, this is definitely going the right direction. I think I only had a couple of minor changes needed to land it...

@stefanpenner
Copy link
Contributor

stefanpenner commented Mar 11, 2017

This code actually now resides within ember itself: https://github.com/emberjs/ember.js/blob/aeeddf7c00b42a340494465252481b5414d87009/packages/ember-extension-support/lib/container_debug_adapter.js (since ember 1.7, but this library accidentally overrode it for compat).

This fix should likely land there, we can always backport here after (for the 2x series)

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

Successfully merging this pull request may close these issues.

None yet

5 participants