TypeSafeApi generated client module format.

[zetashift]

I'm using SvelteKit and a generated Smithy client and experiencing an export/import problem.
When running vite build the following error is thrown:

dashboard: "DefaultApi" is not exported by "../mic-api/runtime/typescript/lib/index.js", imported by "src/lib/server/mic-api-client.ts".
dashboard: file cx/packages/dashboard/src/lib/server/mic-api-client.ts:1:24
dashboard: 1: import { Configuration, DefaultApi } from "mic-api-typescript-runtime";
dashboard:                            ^
dashboard: 2:
dashboard: 3: export const ApiClient = new DefaultApi(
dashboard: error during build:
dashboard: RollupError: "DefaultApi" is not exported by "../mic-api/runtime/typescript/lib/index.js", imported by "src/lib/server/mic-api-client.ts".
dashboard:     at error (file:///cx/node_modules/.pnpm/rollup@3.21.3/node_modules/rollup/dist/es/shared/node-entry.js:2125:30)

I believe it's because the index.js does not export the modules as expected:

__exportStar(require("./runtime"), exports);
__exportStar(require("./apis"), exports);
__exportStar(require("./models"), exports);
__exportStar(require("./apis/DefaultApi/OperationConfig"), exports);

Is there a way to get the TypeSafeApi project to spit out exports like:
export const DefaultApi... way?

I tried doing:

runtime: {
    languages: [Language.TYPESCRIPT],
    options: {
      typescript: {
        name: "cx-api-typescript-runtime",
        defaultReleaseBranch: "main",
        description:
          "Generated typescript packages for our API, from Smithy models",
        tsconfig: {
          compilerOptions: {
            module: "nodenext",
            target: "es2022",
          },
        },
      },
    },
  }

but this throws the same error

[zetashift]

This seems to clear those errors(changing the tsconfig for the TypeSafeApi)

tsconfig: {
          compilerOptions: {
            module: "es2022",
            target: "es2022",
            moduleResolution: javascript.TypeScriptModuleResolution.NODE,
            resolveJsonModule: true,
            esModuleInterop: true,
          },
        }

But then the CDK construct/subproject(which deploys the API to a lambda) throws an error:

mic-platform: export * from './runtime';
mic-platform: ^^^^^^
mic-platform: SyntaxError: Unexpected token 'export'
mic-platform:     at internalCompileFunction (node:internal/vm:73:18)
mic-platform:     at wrapSafe (node:internal/modules/cjs/loader:1153:20)

[zetashift]

Right so recap:

• I couldn't use the generated Smithy client in my SvelteKit because that project uses type: "module" in it's package.json
• Changing the code generated in runtime/typescript/lib/index.js to ESNext makes it usable in my SvelteKit project, but in turn starts a world of hurt with ESM vs CJS in other subprojects.
• I fixed it by reverting all the package.json and tsconfig.json fiddling I had done and to import the client as follows in my SvelteKit project:

import { DefaultApi, Configuration } from "my-api-typescript-runtime/src/index";

I have no idea if this is good or bad...

[cogwirrel]

Hey! Sorry for the slow reply! Glad you found a combination that solved it! 😄

I've experienced hurt with ESM vs CJS before too haha! You can get both building though instead of just choosing between one or the other if that helps :)

Here's an example of how to do it in your .projenrc (courtesy of @zsstiers !):

api.runtime.typescript!.addFields({
  module: "./lib/esm/index.js",
  sideEffects: false,
});
api.runtime.typescript!.compileTask.exec("tsc -p tsconfig.esm.json");
new JsonFile(api.runtime.typescript!, "tsconfig.esm.json", {
  obj: {
    extends: "./tsconfig.json",
    compilerOptions: {
      module: "esnext",
      moduleResolution: "nodenext",
      outDir: "lib/esm",
    },
  },
});

[zetashift]

Thank you!! Finally haha :D.

EDIT: I meant finally no more ESM vs CJS headache btw.

[zetashift]

Is it worth it to make a PR for TypeSafeApiProject that would include a toggle for building both? I could probably whip one up, but I can also imagine the code being not that valuable to include and just copy-pasting this is more than enough

[cogwirrel]

Ooh yes please! Would love a PR if you’re happy to raise one! :)

I reckon just building it by default would be best given it’s an additional artefact that’s probably going to be more useful than not :) I wouldn’t expose a dedicated option to toggle as users can disable it via projen (eg api.runtime.typescript!.tryRemoveFile(“tsconfig.esm.json”))

Also for the extra compile command if you put it in a task like “compile-esm” (and spawn it as part of the compile task) it’s easy for users to get rid of it, eg:

api.runtime.typescript!.tasks.tryFind(“compile-esm”)?.reset()

[zetashift]

I want to open up a draft PR, because I have some questions about including specific code in a task, but I'm getting the following error when trying to commit something:

aws-prototyping-sdk feat/compile-esm-task• 11.2s ❱ pnpm cz
cz-cli@4.3.0, cz-conventional-changelog@3.3.0

? Select the type of change that you're committing: feat:     A new feature
? What is the scope of this change (e.g. component or file name): (press enter to skip) type-safe-api
? Write a short, imperative tense description of the change (max 79 chars):
 (51) add ESM compilation for generated typescript client
? Provide a longer description of the change: (press enter to skip)

? Are there any breaking changes? No
? Does this change affect any open issues? No
.husky/pre-commit: 2: set: Illegal option -o pipefail
git exited with error code 1

EDIT: got it fixed by modifying the pre-commit hook, temporarily commenting out the strict fail checking. I'll add it back in again after the draft is done :P.