-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
@headlessui/react is not compatible with TypeScript 4.7 NodeNext
module resolution.
#1699
Comments
The easier solution is to remove:
from the
|
Hey! Thank you for your bug report! We already rewrote the imports for This should be fixed by #1721, and will be available in the next release. You can already try it using:
When I try this version in your reproduction repo, it seems to not fail as spectacularly as before, however I do get this error now:
I'm debugging this issue right now to see if we have to make more changes to Headless UI itself or not. |
import { StrictMode, type ReactElement } from "react";
import { createRoot } from "react-dom/client";
import React, { useState } from "react";
const people = [
{ id: 1, name: "Durward Reynolds", unavailable: false },
{ id: 2, name: "Kenton Towne", unavailable: false },
{ id: 3, name: "Therese Wunsch", unavailable: false },
{ id: 4, name: "Benedict Kessler", unavailable: true },
{ id: 5, name: "Katelyn Rohan", unavailable: false },
];
async function WHY() {
const { Listbox } = await import("@headlessui/react");
const App = (): ReactElement => {
const [selectedPerson, setSelectedPerson] = useState(people[0]);
return (
<Listbox value={selectedPerson} onChange={setSelectedPerson}>
<Listbox.Button>{selectedPerson.name}</Listbox.Button>
<Listbox.Options>
{people.map((person) => (
<Listbox.Option
key={person.id}
value={person}
disabled={person.unavailable}
>
{person.name}
</Listbox.Option>
))}
</Listbox.Options>
</Listbox>
);
};
createRoot(document.querySelector("#root")!).render(
<StrictMode>
<App />
</StrictMode>
);
}
WHY(); This works, but this is far from ideal of course. I see people recommending to use |
Above you mentioned an error you were still seeing with the
Did you fix it (not counting the |
Hey @scott-lc, so it is working for you? Interesting, I'm on your repo and bumped Headless UI but it's not working or me in this case. However, I tested it on existing projects and it works there jus fine. So if it is working for you than I'm calling this change a success 😅 Screenshot of my changes: |
@RobinMalfait - I have the exact same change and cannot re-create what you are seeing. I too call this change a success. Bravo and thanks.
although that should not matter. |
I did re-create it. My dependency was Without the |
Eventhough I was able to remove the error by installing the insider version, I got another error when i use
as mention in #1419 |
@headlessui/react
What version of that package are you using?
v1.6.6
What browser are you using?
Not a browser issue. Rather this is a TypeScript compiler issue. Environment is:
NodeNext
module resolution in thetsconfig.json
file.Reproduction URL
https://github.com/scott-lc/headlessui-nodenext
Describe your issue
TypeScript 4.7 introduced a new ESM-compliant module resolution specifier called
NodeNext
(details here).One fallout of this is that when compiling TypeScript code with
nodenext
, the compiler expects that code that "claims" to be ESM compliant is actually ESM compliant. How does code claim it is ESM compliant? From TypeScript 4.7'snodenext
module resolution algorithm perspective, the presence of"type": "module"
in the dependency'spackage.json
file indicates that the dependency should be interpreted as ESM.As described here, when a dependency is marked with
"type":"module"
, it is interpreted as an ES Module and "a few different rules come into play". Specifically:The underlying issue is that
@headless-ui/react
is marked as being ESM compliant (`"type":"module"), but it really isn't. In order to be ESM compliant, all imports must use a full extension. This is nothing new and has been true since ESM support was marked as stable sometime back in Node 14.What has changed is that the TypeScript 4.6
esnext
/node
module resolver did not care. It happily consumed code that was missing extensions or made assumptions about auto-resolvingindex.xx
files when importing a directory. In fact, Node itself has a flag to resolve modules "the old way".However, when using TypeScript 4.7
nodenext
module resolution algorithm and things fail spectacularly:What does this mean for
@headlessui/react
? It really should be as straightforward as adding.js
extensions to the typescript code as described here.The text was updated successfully, but these errors were encountered: