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

Fixing bug - named AMD modules were instantiated twice. Resolves #2103. #2104

Merged
merged 3 commits into from
Jan 17, 2020

Conversation

joeldenning
Copy link
Collaborator

@joeldenning joeldenning commented Jan 16, 2020

See #2103.

@guybedford I'd appreciate your thoughts on this.

@@ -11,7 +11,7 @@ suite('Named System.register', function() {

test('Loading a named AMD bundle', function () {
return System.import('./fixtures/browser/named-amd.js').then(function (m) {
assert.equal(Object.keys(m).length, 2);
assert.equal(m.a, 'b');
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This test was making a weird assertion that I think was wrong. On the master branch, m is {__useDefault: true, default: {}}. Even though named-amd.js registers two modules that have values in them.

With my changes in this PR, m becomes the c module defined here. This is similar behavior to how the named-register extra keeps track of the firstNamedDefine. I updated the assertions to verify that the c module is being returned now.

Copy link
Member

Choose a reason for hiding this comment

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

This seems ok to me.

@@ -88,6 +88,10 @@
if (register && register[1] === lastRegisterDeclare)
return register;

// If the script registered a named module, return that module instead of re-instantiating it.
if (firstNamedDefine)
return firstNamedDefine;
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Before this PR, we were calling createAMDRegister() multiple times for the same AMD module. This is problematic because (1) some modules rely on their code only being executed once, and (2) performance of running the execute function multiple times.

Copy link
Member

@guybedford guybedford left a comment

Choose a reason for hiding this comment

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

Handling named AMD support has always been tricky because AMD itself never properly defined what it means to require a bundle.

In theory this is likely a breaking change, but let's push it out rather and roll back if there are bugs.

firstNamedDefine = define;
setTimeout(function () {
firstNamedDefine = null;
});
Copy link
Member

Choose a reason for hiding this comment

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

We shouldn't rely on a setTimeout. Rather we should clear this when we know it is safe to clear it. If this code path is the only knowledge that we should clear it then perhaps we should have a shouldClearNamedDefine variable.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I thought through how to do this without setTimeout earlier - one approach I considered to was to reset firstNamedDefine inside of getRegister(), or perhaps inside of instantiate.

Could you explain how this shouldClearNamedDefine variable would work?

@@ -11,7 +11,7 @@ suite('Named System.register', function() {

test('Loading a named AMD bundle', function () {
return System.import('./fixtures/browser/named-amd.js').then(function (m) {
assert.equal(Object.keys(m).length, 2);
assert.equal(m.a, 'b');
Copy link
Member

Choose a reason for hiding this comment

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

This seems ok to me.

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

Successfully merging this pull request may close these issues.

2 participants