You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I know it's an alias of HResult, which can be imported from lib/core, but it isn't idiomatic, and lib/core currently isn't exposed, so it doesn't work in this module resolution mode.
The node16 resolution type is the correct one for native ESM, and therefor for unified packages internally. Unfortunately not all of the ecosystem is compatible yet (davidbonnet/astring#646). This needs to be resolved first, then I can look at how all of this affects hastscript.
A quick history on this topic:
At first the TypeScript JSX namespace had to be global.
declare global {namespaceJSX{// …}}
During this time the React types were created.
At some point TypeScript allowed specifying local JSX namespaces
declarefunctionh();namespaceh.JSX{// …}
This allows people to mix multiple JSX implementations in different filed within the same project 🤯 So these two files could live in the same project:
// react-hello.tsx
/* @jsx h */import{h}from'hastscript'constHello=()=><div>Hello</div>
Then the automatic runtime was released.
As far as I know, this requires a global JSX namespace. However, this issue suggests this is incorrect. If this is indeed incorrect, then IMO it is the desired behaviour, because it would allow to mix multiple JSX implementationg using JSX comments.
I do think it would be nice to expose the HResult type though. I totally agree it makes sense to use this type, i.e. for explicit return types as the OP suggests.
Thanks, that makes sense! So I went ahead and checked if anybody has reported this in TypeScript, since this feels like their responsibility, and I found something even better: microsoft/TypeScript#41330 (comment) Here's how Preact implemented it: https://github.com/preactjs/preact/pull/2811/filesEdit: And I see that it's already exported, so why doesn't it work? Edit 2: Ah, likely because it isn't re-exported here and here and here. Edit 3: No, I still don't understand why this isn't sufficient:
Edit 4: Okay, finally found the definitive answer to this: microsoft/TypeScript#47072 (comment) The JSX namespace is an implementation detail, not meant to be public. So, in the end, import { HResult } is the way to go.
Activity
wooorm commentedon Aug 22, 2022
Sounds like something @remcohaszing has ideas on!
remcohaszing commentedon Aug 22, 2022
The
node16resolution type is the correct one for native ESM, and therefor for unified packages internally. Unfortunately not all of the ecosystem is compatible yet (davidbonnet/astring#646). This needs to be resolved first, then I can look at how all of this affectshastscript.A quick history on this topic:
// react-hello.tsx
As far as I know, this requires a global JSX namespace. However, this issue suggests this is incorrect. If this is indeed incorrect, then IMO it is the desired behaviour, because it would allow to mix multiple JSX implementationg using JSX comments.
I do think it would be nice to expose the
HResulttype though. I totally agree it makes sense to use this type, i.e. for explicit return types as the OP suggests.alecmev commentedon Aug 22, 2022
Thanks, that makes sense! So I went ahead and checked if anybody has reported this in TypeScript, since this feels like their responsibility, and I found something even better: microsoft/TypeScript#41330 (comment) Here's how Preact implemented it: https://github.com/preactjs/preact/pull/2811/files Edit: And I see that it's already exported, so why doesn't it work? Edit 2: Ah, likely because it isn't re-exported here and here and here. Edit 3: No, I still don't understand why this isn't sufficient:
Edit 4: Okay, finally found the definitive answer to this: microsoft/TypeScript#47072 (comment) The JSX namespace is an implementation detail, not meant to be public. So, in the end,
import { HResult }is the way to go.wooorm commentedon Aug 23, 2022
As far as I understand the above comments, then it would be bad to do this?
And exposing
HResultis an adequate solution?alecmev commentedon Aug 23, 2022
Yep! Looks like
JSXisn't meant to be accessed ever.I believe so. The name is a little cryptic, but it's not worth a refactor, and breaking existing consumers.
wooorm commentedon Aug 24, 2022
I’m up for exposing
HResult, I don’t see downsides.@alecmev Interested in working on a PR?
[-]Expose JSX namespace globally[/-][+]Expose ~JSX namespace~ `HResult` globally[/+]github-actions commentedon Aug 24, 2022
github-actions commentedon Oct 10, 2022
wooorm commentedon Oct 10, 2022
Released in 7.1.0!
I noticed that HChild, HProperties, were also exposed as
ChildandProperties, so I usedResultas the type name for thisalecmev commentedon Dec 22, 2022
Sorry for the radio silence, thank you!