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

refactor(ses): Retool for module descriptors #2321

Merged
merged 7 commits into from
Jul 15, 2024

Conversation

kriskowal
Copy link
Member

@kriskowal kriskowal commented Jun 13, 2024

Refs: #400 #2251

Description

Pursuant to arriving at parity with XS, this change internally reörients the SES module loader around the concept of a “module descriptor”. This creates some clarity and removes some existing duplication of work for “alias” module descriptors, and prepares the material for a richer module descriptor schema to match those implemented by XS.

Security Considerations

No changes.

Scaling Considerations

No changes.

Documentation Considerations

No changes.

Testing Considerations

No changes.

Compatibility Considerations

No changes.

Upgrade Considerations

No changes.

@kriskowal kriskowal requested a review from naugtur June 13, 2024 22:19
@kriskowal kriskowal marked this pull request as draft June 13, 2024 23:03
@kriskowal kriskowal force-pushed the kriskowal-ses-module-descriptors-refactor branch 3 times, most recently from 176f710 to 4d3a95b Compare June 14, 2024 00:46
@kriskowal kriskowal marked this pull request as ready for review June 14, 2024 00:57
@kriskowal kriskowal force-pushed the kriskowal-ses-module-descriptors-refactor branch 2 times, most recently from 0a6fbb9 to 62fe754 Compare June 20, 2024 23:51
Copy link
Contributor

@erights erights left a comment

Choose a reason for hiding this comment

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

I probably need a live discussion before I'm knowledgeable enough to complete the review. But a lot already LGTM

packages/ses/src/compartment.js Outdated Show resolved Hide resolved
packages/ses/src/compartment.js Outdated Show resolved Hide resolved
@erights erights self-requested a review June 22, 2024 02:23
@kriskowal kriskowal force-pushed the kriskowal-ses-module-descriptors-refactor branch 7 times, most recently from 194959e to 2d7ace2 Compare July 3, 2024 01:06
packages/ses/src/module-load.js Show resolved Hide resolved
packages/ses/src/module-load.js Show resolved Hide resolved
packages/ses/src/module-load.js Show resolved Hide resolved
packages/ses/src/module-load.js Show resolved Hide resolved
Comment on lines +245 to +249
// A (legacy) behavior: If we do not recognize the module descriptor as a
// module descriptor, we assume that it is a module source (record):
Copy link
Member Author

Choose a reason for hiding this comment

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

At some point, we’ll want to add options for strict portability and this case will become an exception in that mode. We would stop trying to differentiate module sources from module descriptors.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm fine with the code here in this PR. But I don't understand the comment. Why not continue to differentiate module sources from module descriptors?

Copy link
Member Author

Choose a reason for hiding this comment

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

We’ve discriminated all the module descriptors up to this point, but to preserve backward compatibility with import hooks that simply returned a module source (not a module source wrapped in a module descriptor), we have to fall through here.

We do have a clear path to deprecate this path, though, which I hope to get to separately.

Copy link
Contributor

Choose a reason for hiding this comment

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

which I hope to get to separately

Worth filing an issue?

@kriskowal kriskowal force-pushed the kriskowal-ses-module-descriptors-refactor branch 7 times, most recently from caf80a9 to db465e4 Compare July 12, 2024 23:58
Copy link
Contributor

@erights erights left a comment

Choose a reason for hiding this comment

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

Sorry it took so long.

LGTM, thanks!

}
if (typeof aliasNamespace === 'string') {

if (typeof moduleDescriptor === 'string') {
// eslint-disable-next-line @endo/no-polymorphic-call
assert.fail(
Copy link
Contributor

Choose a reason for hiding this comment

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

On the function declaration, I'm currently getting the lint warning

  131:11  warning  Expected to return a value at the end of generator function 'loadWithoutErrorAnnotation'  consistent-return

but if I change this line to

Suggested change
assert.fail(
throw assert.fail(

and (see below)

Copy link
Member Author

Choose a reason for hiding this comment

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

This presumably means that the type isn’t getting properly threaded, since fail and Fail return never. I’ll change this to throw assert.error since throwing at an inevitably throwing call feels weird.

Copy link
Contributor

Choose a reason for hiding this comment

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

It felt weird for me the first 100 times. But our codebase now does that pervasively. In throw Fail... I read the Fail as "throw an error" and the throw as "Let static analysis know that we're throwing an error".

moduleLoads,
);
} else {
Fail`module descriptor must be a string or object for specifier ${q(
Copy link
Contributor

Choose a reason for hiding this comment

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

(continued from above)
and modify this line to

Suggested change
Fail`module descriptor must be a string or object for specifier ${q(
throw Fail`module descriptor must be a string or object for specifier ${q(

the warning goes away.

packages/ses/src/module-load.js Show resolved Hide resolved
Comment on lines 105 to 110
moduleMapHook(specifier) {
if (specifier === './index.js') {
return new StaticModuleRecord('export default 42');
}
},
Copy link
Contributor

Choose a reason for hiding this comment

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

I get 7 consistent return lint warnings in this file.

Suggested change
moduleMapHook(specifier) {
if (specifier === './index.js') {
return new StaticModuleRecord('export default 42');
}
},
moduleMapHook(specifier) {
if (specifier === './index.js') {
return new StaticModuleRecord('export default 42');
}
return undefined;
},

packages/ses/src/module-load.js Show resolved Hide resolved
packages/ses/src/module-load.js Show resolved Hide resolved
packages/ses/src/module-load.js Show resolved Hide resolved
packages/ses/src/module-load.js Show resolved Hide resolved
Comment on lines +245 to +249
// A (legacy) behavior: If we do not recognize the module descriptor as a
// module descriptor, we assume that it is a module source (record):
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm fine with the code here in this PR. But I don't understand the comment. Why not continue to differentiate module sources from module descriptors?

@kriskowal kriskowal force-pushed the kriskowal-ses-module-descriptors-refactor branch from db465e4 to 5df0f1a Compare July 15, 2024 22:54
@kriskowal kriskowal merged commit a62e766 into master Jul 15, 2024
17 checks passed
@kriskowal kriskowal deleted the kriskowal-ses-module-descriptors-refactor branch July 15, 2024 23:05
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.

None yet

2 participants