ESM conversion, Remix v2, shadcn/ui

[PhilDL]

ESM Conversion

More and more libraries in the ecosystem take the decision to be ESM only, integrating the remark/rehype ecosystem often leads to have an enormous list serverDependenciesToBundle.

What changed

• The remix-app is now ESM with a very similar setup to the epic-stack
• The server.ts changed and was split to different folder (similar to the epic stack)
• The Dockerfile was changed accordingly
• Some of the packages were converted to ESM also
• The corresponding commit is bdd8e98

Playwright replaced Cypress

• I switched Cypress for Playwright and updated the GitHub CI to reflect that. The setup is now simplified.

UI packages now integrate shadcn/ui components

• The package was improved to give a potentially more realistic setup
• It exports a tailwind preset and a tailwind config. (You should use the preset in the app consuming the UI)
• It exports different components (not the whole library, import what you need)
• The package is transpiled, and the types are exposed directly from the source. Hybrid strategy: same as the "internal-no-build" package + bundling the tailwind folder to export the tailwind config.

[natac13]

I have a question about the reason behind including the ui package in the serverDependenciesToBundle array.
I understand the reasoning behind doing so with the internal-nobuild package but with the ui package using tsup for the build step I am wondering why it is in the array? Im not saying anything is wrong I just trying to step up my own monorepo with my apps deploying to vercel. And since Im using the @vercel/remix package, and it having for instructions to use cjs I am not quite able to make the switch just yet.

My dilemma at the moment is the only way I was able to get the remix app deployed to vercel was to follow the turbo repo's kitchen sink example and and bundle all the ui components into one file. I just like your setup much better and like that you separated the "use client" statements as needed.

[PhilDL]

TLDR: I updated the repo with a new remix app called `remix-cjs" that is deployed to Vercel here: https://remix-gospel-stack-remix-cjs.vercel.app/ take a look at the setup maybe it will help you.

Hi @natac13 ! This repository gets updated when I find a better setup in my current private productions projects and the serverDependenciesToBundle is a residual piece of code when the Remix app was CJS and UI package was bundled.

The current setup can be misleading, I am sorry, it's really in between different ideas I had at the time.

Bundling UI components or not.

Yes, you can see a separation of client and server components, but the tsup output actually points the imports to the source files xxxx.tsx so I am not really using the output of tsup except for the index and the tailwind/index files that contain respectively a utility function and a tailwind preset.

In my most recent setup I don't bundle the components at all and just programmatically create the entries in package.json that points the import and types directly to the typescript files. It looks more like this:

import { readFile, writeFile } from "fs/promises";
import { defineConfig, type Options } from "tsup";

const client = [
  "./src/checkbox.tsx",
];

const server = [
  "./src/button.tsx",
  "./src/card.tsx",
];

export default defineConfig((opts) => {
  const common = {
    clean: !opts.watch,
    dts: true,
    format: ["esm"],
    minify: true,
    outDir: "dist",
  } satisfies Options;

  return [
    {
      ...common,
      entry: ["./src/index.ts", "./src/tailwind/index.ts"],
      async onSuccess() {
        const pkgJson = JSON.parse(
          await readFile("./package.json", {
            encoding: "utf-8",
          }),
        ) as PackageJson;
        pkgJson.exports = {
          "./package.json": "./package.json",
          ".": {
            import: "./src/index.ts",
            types: "./src/index.ts",
            default: "./dist/index.mjs",
          },
          "./tailwind": {
            import: "./src/tailwind/index.ts",
            types: "./src/tailwind/index.ts",
            default: "./dist/tailwind/index.mjs",
          },
        };
        [...client, ...server]
          .filter((e) => e.endsWith(".tsx"))
          .forEach((entry) => {
            const file = entry.replace("./src/", "").replace(".tsx", "");
            pkgJson.exports["./" + file] = {
              import: "./src/" + file + ".tsx",
              types: "./src/" + file + ".tsx",
            };
            pkgJson.typesVersions["*"][file] = ["src/" + file + ".tsx"];
          });

        await writeFile("./package.json", JSON.stringify(pkgJson, null, 2));
      },
    },
  ];
});

type PackageJson = {
  name: string;
  exports: Record<
    string,
    { import: string; types: string; default?: string } | string
  >;
  typesVersions: Record<"*", Record<string, string[]>>;
  files: string[];
  dependencies: Record<string, string>;
  pnpm: {
    overrides: Record<string, string>;
  };
};

As you can see, the entry point doesn't contain any component. We just update the package.json exports.

If you really want to bundle your UI package, you should update that config to add format: ["cjs"] and update the package.json generation with require statements pointing to the index.js version and types to index.d.ts of each component in the forEach loop.

serverDependenciesToBundle array

In the current setup without bundling + the use "paths" in the tsconfig.json we don't have to fill the serverDependenciesToBundle array for that UI package.

tsconfig.json

"paths": {
      "~/*": ["./app/*"],
      "@remix-gospel-stack/ui/*": [
        "../../packages/ui/src/*"
      ],
      "@remix-gospel-stack/ui": [
        "../../packages/ui/src/index"
      ],
      "@remix-gospel-stack/internal-nobuild": [
        "../../packages/internal-nobuild/src/index"
      ],
      "@remix-gospel-stack/internal-nobuild/*": [
        "../../packages/internal-nobuild/src/*"
      ],
    },

I updated the repo with a new remix app called `remix-cjs" that is deployed to Vercel here: https://remix-gospel-stack-remix-cjs.vercel.app/ take a look at the setup maybe it will help you.

[natac13]

Thank you for the help!

I have updated my repo to follow what you have told me here. Plus I updated my .npmrc file to match yours. sidenote: Which I think helped me figure out why my prisma client was not working like yours as well. 🚀 🙏 TY

However, the one thing that still is not fully working is vscode auto import of ui components in the remix app specifically. The next app auto imports fine. I did some digging and found that TS will only auto import from package.json.exports if tsconfig.json has the following:

  "compilerOptions": {
    ...
    "moduleResolution": "NodeNext", // remix has 'Node'
    "module": "NodeNext", // remix has 'CommonJS'
  }

I know that soonish Remix is going to v2 which is esm by default and therefore the tsconfig.json would get changed as above.
And since I just tested these changes work when deployed to vercel I think I will leave it for now and deal without the auto import.
I just much prefer your setup to the kitchen sink version where the ui package is bundled separate.

Also one note.
The remix app auto imports the shadcnpreset as expected, however the next app did not until I added the following

"typesVersions": {
    "*": {
      "tailwind": [
        "src/tailwind/index.ts"
      ],
    ... other components
  }

[Jarrodsz]

To add i also had many issues with the esm only approach and 1 specific issue with a database orm not supporting it yet.

so i switched back to cjs instead of esm.
Would this cause issues if the whole stack converts to esm? I hope begin next uear rhey have there esm compatibility on par so we can them switch back to that.

[PhilDL]

I updated the stack recently so you can see the new tsconfigs.

I think you will have a better time with the following config for the remix-app in the monorepo:

• "type": "module" in your package.json
• tsconfig with the following moduleResolution Bundler:

    "module":"ESNext",
    "moduleResolution": "Bundler",
    "resolveJsonModule": true,
    "target": "ESNext",

This will also be the new standard when vite + remix become production ready.

This "Bundler" should solve a lot of problem of modules that don't have ESM output.