-
Notifications
You must be signed in to change notification settings - Fork 71
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
feat(endo): Search for index.js and implied package exports #424
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand all the details, but here are some comments.
packages/endo/DESIGN.md
Outdated
|
||
// ExitName is the name of a built-in module, to be threaded in from the | ||
// modules passed to the module executor. | ||
type ExitName string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
type ExitName string; | |
type ExitName = string; |
// In Node.js, an absolute specifier always indicates a built-in or | ||
// third-party dependency. | ||
// The `moduleMapHook` captures all third-party dependencies. | ||
if (moduleSpecifier !== "." && !moduleSpecifier.startsWith("./")) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you also need to handle
&& moduleSpecifier !== '..' && !moduleSpecifier.startsWith('../')
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be good in general to validate the moduleSpecifier. Any specifier that starts with ../
is invalid because it escapes the package root. I have a utility that throws if a module specifier escapes the package root in general, which I could use as a guard here.
const types = {}; | ||
|
||
Object.assign(result, { | ||
label: `${name}${version ? `-v${version}` : ""}`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would @version
be better, to help avoid naming collisions.
label: `${name}${version ? `-v${version}` : ""}`, | |
label: `${name}${version ? `@${version}` : ""}`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was previously using name@version#number
for compartment labels in archives, and quickly got in trouble when using URL math with them. I might try again, but they would end up %
encoded.
dde4c78
to
f6210c3
Compare
5085ce0
to
93283e3
Compare
f6210c3
to
389d7cd
Compare
93283e3
to
de0ea45
Compare
389d7cd
to
32d4fe6
Compare
de0ea45
to
2b7a5f9
Compare
32d4fe6
to
0222f73
Compare
2b7a5f9
to
b945563
Compare
0222f73
to
78d1f0f
Compare
When asked for a module named "x", Node.js will search for "x.js" then "x/index.js". For packages that do not supply an "exports" property in their "package.json", any module contained by that package is a valid exported module. To achieve parity with these two features, Endo uses different techniques when loading from the file system and loading from an archive. When reading from the file system, Endo will search for a satsifactory candidate in each compartment's asynchronous importHook. Endo also uses the compartment's new moduleMapHook to search for dependency compartments in the "scope" of a module identifier prefix. These allow Endo to operate from an incomplete compartment map for the initial load. The Endo archiver instead creates a more complete compartment map, with every discovered module. This introduces a new kind of module to the compartment map module descriptor type union: modules with known locations and corresponding parsers. The archiver erases the "scopes", "types", and "parsers" on each compartment description since they are no longer necessary. When reading from an archive, Endo uses an importHook that consults the compartment map directly for the locations of all contained modules, and creates a complete moduleMap up front.
b945563
to
9153014
Compare
78d1f0f
to
444b063
Compare
cb1fcad
to
bf310ac
Compare
Looks like I messed up the stack and that this was a duplicate of #434 |
When asked for a module named "x", Node.js will search for "x.js" then "x/index.js".
For packages that do not supply an "exports" property in their "package.json", any module contained by that package is a valid exported module.
To achieve parity with these two features, Endo uses different techniques when loading from the file system and loading from an archive.
When reading from the file system, Endo will search for a satsifactory candidate in each compartment's asynchronous importHook. Endo also uses the compartment's new moduleMapHook to search for dependency compartments in the "scope" of a module identifier prefix. These allow Endo to operate from an incomplete compartment map for the initial load.
The Endo archiver instead creates a more complete compartment map, with every discovered module. This introduces a new kind of module to the compartment map module descriptor type union: modules with known locations and corresponding parsers. The archiver erases the "scopes", "types", and "parsers" on each compartment description since they are no longer necessary.
When reading from an archive, Endo uses an importHook that consults the compartment map directly for the locations of all contained modules, and creates a complete moduleMap up front.