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

Embroider crash when initializer/instance-initializer does not have a default export #277

Open
mehulkar opened this issue Nov 3, 2020 · 6 comments

Comments

@mehulkar
Copy link
Contributor

mehulkar commented Nov 3, 2020

If you have an initializer that does not have a default export:

export function initialize() {}

// export default { initialize } 

resolveInitializer crashes here:

var initializer = module['default'];
if (!initializer.name) {

This function only seems to be called when I enable Embroider builds, not in regular ember-cli builds, so I'm not sure if this is intentional or what the expectations are.

ember-cli could be stricter and require this default export, but if it's intentional to not require the default export, then resolveInitializer should handle this case as well?

@mehulkar
Copy link
Contributor Author

mehulkar commented Nov 3, 2020

It seems that ember-cli may not be using the default export, and it's just using the named export, but I'm not sure if the object here is the module or not.

https://github.com/emberjs/ember.js/blob/ec49e0eee542791ca6916a71096988acab9c2ec0/packages/%40ember/engine/index.js#L124

@rwjblue
Copy link
Member

rwjblue commented Nov 3, 2020

This function only seems to be called when I enable Embroider builds, not in regular ember-cli builds, so I'm not sure if this is intentional or what the expectations are.

I don't fully understand what you mean here. Are you saying that in ember-cli's build pipeline that initialize function is never invoked, but in Embroiders it is invoked? Or are you saying the reverse (called in ember-cli pipeline but not in Embroider)?

I believe these are related references:

@mehulkar
Copy link
Contributor Author

mehulkar commented Nov 3, 2020

This function only seems to be called when I enable Embroider builds, not in regular ember-cli builds, so I'm not sure if this is intentional or what the expectations are.

I don't fully understand what you mean here.

I was totally wrong here. the function is called in both.

The difference seems to be that when the default export is missing, with regular ember builds, module.default is circular:

{ initialize: [Function: initialize], default: [Circular] }

So it doesn't cause a crash while registering the initializers.

With Embroider, maybe require is being changed, causing the circular structure not to happen?

@mehulkar
Copy link
Contributor Author

mehulkar commented Nov 3, 2020

I've made simple repro here (see commit history): https://github.com/mehulkar/embroider-initializer-crash. The easiest workaround is to just add the default exports into my initializers, but I think resolveInitializer should explicitly throw when module.default is undefined, so that adopting Embroider doesn't cause this, kind of hard to track problem.

@rwjblue
Copy link
Member

rwjblue commented Nov 3, 2020

Right, you are describing the same thing that is described in the issues I linked in my initial comment. If you use the flag to disable the default export munging in loader.js you will have the same behavior in both worlds.

@mehulkar
Copy link
Contributor Author

mehulkar commented Nov 3, 2020

How do I use this flag? I looked ovr that issue but don't see how to do it from the standpoint of ember-cli. Not sure where loader.js gets invoked.

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

No branches or pull requests

2 participants