-
Notifications
You must be signed in to change notification settings - Fork 74
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
fix(ses): fix types export for newer module resolutions #1840
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.
The changes to package.json
is fine. It's necessary given the way the "exports" and "types" fields work.
packages/ses/types.d.ts
Outdated
@@ -59,7 +59,7 @@ export interface ThirdPartyStaticModuleInterface { | |||
imports: Array<string>; | |||
exports: Array<string>; | |||
execute( | |||
proxiedExports: Object, | |||
proxiedExports: Record<PropertyKey, any>, |
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'll defer the review of this change to @kriskowal
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.
The problem with Object
is that you cannot assign to it. You can't assign to object
, either.
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.
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.
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.
Yep! It's string | number | symbol
from the es5
internal lib.
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.
Is this object parameter meant to be mutated? That seem contrary to our programming model of hardening what is passed.
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.
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]
.
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.
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.
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.
@naugtur Understood. This begs the question, though, should Object.keys()
be used there, and not, say, Object.getOwnPropertyDescriptors()
?
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've updated the comment.
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'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" |
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.
Can you add a line to package.json.md
explaining this?
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.
@kriskowal Done. Also fixed another path in there that was wrong.
47dbf9c
to
0e819f3
Compare
@kriskowal Looks like CI needs to be burped |
f8424fd
to
61db03b
Compare
Please note that #1803 is the same sort of thing but for |
61db03b
to
266aab5
Compare
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.
266aab5
to
fe38c40
Compare
Much like #1803, this adds
types
conditional exports where appropriate.Additionally, I fixed a type in
ThirdPartyStaticModuleInterface
which I was bumping up against.