Consider simplifying type exports and require moduleResolution: bundler

[gunters63]

Describe the bug

(Some) Ladle Types cannot be resolved correctly with Node16 resolution

Reproduction

• pnpm create vite my-react-app --template react-ts
• pnpm i
• Add a story using a decorator, the example from the website is sufficient:

import type { Story, StoryDecorator } from "@ladle/react";

export default {
  decorators: [
    (Component, context) => (
      <div style={{ margin: "3em" }}>
        {context.globalState.control.label.value}
        <Component />
      </div>
    ),
  ] as StoryDecorator[],
};

const Card: Story<{
  label: string;
}> = ({ label }) => <p>Label: {label}</p>;

Card.args = {
  label: "Hello",
};

• pnpm tsc --noemit shows no errors:
• Change node resolution to Node16 in tsconfig.json
• pnpm tsc --noemit shows now errors:

[gunters63]

I am quite sure this was introduced with the fix for #267

[gunters63]

The package.json exports looks a bit odd now (in the sense of non-standard), with a "default" entry pointing to a .ts file and types pointing to .d.ts files containing a copy of all types. Maybe the Typescipt compiler gets confused by this.

Interestingly, if i delete the types entry in Ladles packages.json exports Typescript complains about missing .js extensions in the ladle dist sources. When I add them everything works as expected. I can even switch back to the default node resolution.

[tajo]

I can reproduce this too.

Interestingly, if i delete the types entry in Ladles packages.json exports Typescript complains about missing .js extensions in the ladle dist sources. When I add them everything works as expected. I can even switch back to the default node resolution.

That's expected and the reason why for the recent changes.

@frehner Any idea how to fix this?

[gunters63]

I think a cleaner approach would be deploying/tsc-compiling everything needed to a dist folder and just point the exports in package.json to dist/exports.js and dist/exports.d.ts.

I am using this approach in my Monorepo where the web application importing packages built this way is using Vite. This works without a problem, Vite is just using the .js files from the packages without recompiling them.

[gunters63]

I could try to make a merge request using this approach.

[frehner]

I can reproduce this too.

Interestingly, if i delete the types entry in Ladles packages.json exports Typescript complains about missing .js extensions in the ladle dist sources. When I add them everything works as expected. I can even switch back to the default node resolution.

That's expected and the reason why for the recent changes.

@frehner Any idea how to fix this?

The TLDR is that because the source code isn't using file extensions in import paths, and NodeNext/Node16 are strict about explicitly using file extensions, then TS can't find the file.

For example, in the reproduction above, you'll note that Story is found:

That's because Story is part of the main file that we point directly to in package.json. However, StoryDecorator isn't found - and that's because the import statement ../shared/types doesn't have a file extension on it, so technically NodeNext TS can't find that file.

So yeah. That's why. ☹️

How to fix it would potentially mean adding file extensions to all of your import statements. Or maybe seeing what @gunters63 output looks like and seeing what happens there.

---

During this, I also found an issue with my previous PR that I needed to fix. PR coming shortly.

[gunters63]

Adding file extensions and not using Node16 resolution seems risky. It would be easy to forget an extension (when adding/changing code) and tsc would not complain.

Btw, I tried to convert Ladle to Node16 resolution (gave it about 1 hour time) but ran into strange problems with the vite react and the vite tsconfig plugins which do not play well with Node16 resolution yet and also had two type errors with some code consuming AST structures which i couldn't fix.

I think the safest route is just to do it the standard way, let the package exports point to .(c)js and .d.ts files which means adding a tsc transpile step and deploy the .js and .d.ts files with other needed assets to a dist folder.

[frehner]

Adding file extensions and not using Node16 resolution seems risky. It would be easy to forget an extension (when adding/changing code) and tsc would not complain.

There are lint rules for it, if that's any consolation. https://github.com/import-js/eslint-plugin-import#importextensions

But yeah, this is annoying. There is some movement on TS's side of things to make this better, but it won't be out for a bit I suspect.

[tajo]

There is some movement on TS's side of things to make this better, but it won't be out for a bit I suspect.

How about this https://devblogs.microsoft.com/typescript/announcing-typescript-5-0-beta/#moduleresolution-bundler?

[gunters63]

There is some movement on TS's side of things to make this better, but it won't be out for a bit I suspect.

How about this https://devblogs.microsoft.com/typescript/announcing-typescript-5-0-beta/#moduleresolution-bundler?

That could be indeed the solution, lets see when Typescript 5 releases in March :)

[frehner]

There is some movement on TS's side of things to make this better, but it won't be out for a bit I suspect.

How about this https://devblogs.microsoft.com/typescript/announcing-typescript-5-0-beta/#moduleresolution-bundler?

Yup that's the one!