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

fix(ses): fix types export for newer module resolutions #1840

Merged
merged 2 commits into from
Nov 6, 2023

Conversation

boneskull
Copy link
Contributor

Much like #1803, this adds types conditional exports where appropriate.

Additionally, I fixed a type in ThirdPartyStaticModuleInterface which I was bumping up against.

Copy link
Contributor

@mhofman mhofman left a comment

Choose a reason for hiding this comment

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

The changes to package.json is fine. It's necessary given the way the "exports" and "types" fields work.

@@ -59,7 +59,7 @@ export interface ThirdPartyStaticModuleInterface {
imports: Array<string>;
exports: Array<string>;
execute(
proxiedExports: Object,
proxiedExports: Record<PropertyKey, any>,
Copy link
Contributor

Choose a reason for hiding this comment

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

I'll defer the review of this change to @kriskowal

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The problem with Object is that you cannot assign to it. You can't assign to object, either.

Copy link
Member

Choose a reason for hiding this comment

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

And I defer to the submitter since we can rely on @boneskull to answer support questions on Matrix going forward :-). I have no idea. Did not know PropertyKey was a TS built-in.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yep! It's string | number | symbol from the es5 internal lib.

Copy link
Contributor

Choose a reason for hiding this comment

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

Is this object parameter meant to be mutated? That seem contrary to our programming model of hardening what is passed.

Copy link
Member

@kriskowal kriskowal Oct 30, 2023

Choose a reason for hiding this comment

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

Summoning @naugtur to rule on the ESM<->CJS namespace bindings behavior for symbols. My perception is that they would appear on namespace.default[symbol] but not be replicated as namespace[symbol].

Copy link
Member

@naugtur naugtur Oct 31, 2023

Choose a reason for hiding this comment

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

So the value of exports as visible from inside of CJS modules is really best described as any because you can do module.exports = function(){} etc.
That exports reference then gets assigned to namespace.default.
The named exports get populated by iterating over keys on that default export. The key (pun intended) question is which keys are taken into account and I'm using Object.keys there which skips over symbols.
I'm also pretty sure the cjs-module-analyzer is not going to pick up symbols. (I'm trying to prove myself wrong with a testcase now. [edit] Confirmed - there's no way the static analysis the lexer there is capable of is finding symbol references.)

In conclusion, I support Record<string, any> and the comment about the ESM/CJS difference seems invalid.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@naugtur Understood. This begs the question, though, should Object.keys() be used there, and not, say, Object.getOwnPropertyDescriptors()?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've updated the comment.

Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure if it's possible for whatever Object.keys would skip to be detected as named exports by the lexer and only the pre-defined top-level fields will be able to populate from cjs to esm. But I can't say you're not right pointing that out.

One case I can think of is having a getter for lazy loading. I wonder if copying a getter over would even work as intended.

@@ -36,11 +36,13 @@
"exports": {
".": {
"import": "./index.js",
"require": "./dist/ses.cjs"
"require": "./dist/ses.cjs",
"types": "./types.d.ts"
Copy link
Member

Choose a reason for hiding this comment

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

Can you add a line to package.json.md explaining this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@kriskowal Done. Also fixed another path in there that was wrong.

@boneskull boneskull force-pushed the boneskull/fix-type-exports-ses branch from 47dbf9c to 0e819f3 Compare October 30, 2023 19:11
@boneskull
Copy link
Contributor Author

@kriskowal Looks like CI needs to be burped

@boneskull boneskull force-pushed the boneskull/fix-type-exports-ses branch 3 times, most recently from f8424fd to 61db03b Compare October 31, 2023 21:00
@boneskull
Copy link
Contributor Author

boneskull commented Oct 31, 2023

Please note that #1803 is the same sort of thing but for @endo/compartment-mapper (and is awaiting approvals)

@boneskull boneskull force-pushed the boneskull/fix-type-exports-ses branch from 61db03b to 266aab5 Compare November 6, 2023 22:13
Much like endojs#1803, this adds `types` conditional exports where appropriate.
The `proxiedExports` param to the `execute` function cannot be `Object`, which is the literal `Object`.  It must be _some_ kind of `Object`, however, a `Record` is suitable.

However, the property can be a `PropertyKey` if the exports come from CommonJS and can only be a `string` if the exports come from ESM. Use `string` for now and we can widen the type later.
@boneskull boneskull force-pushed the boneskull/fix-type-exports-ses branch from 266aab5 to fe38c40 Compare November 6, 2023 22:19
@kriskowal kriskowal enabled auto-merge November 6, 2023 22:20
@kriskowal kriskowal merged commit b2cb361 into endojs:master Nov 6, 2023
14 checks passed
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.

4 participants