Bad behaviour with default import because of esModuleInterop ?

[mastondzn]

I was trying to use this package with @rollup/plugin-typescript to resolve and edit paths in emitted .d.ts files and the hacky way i finally made it work is like this:

// rollup.config.js
import typescript from "@rollup/plugin-typescript";
import { defineConfig } from "rollup";

/** @type {import("typescript-transform-paths").default} */
const transformPaths = (await import("typescript-transform-paths")).default.default;
// "typescript-transform-paths" has a broken default export

export default defineConfig({
  input: "src/index.ts",
  output: [
    { file: "dist/index.cjs", sourcemap: true, format: "cjs" },
    { file: "dist/index.js", sourcemap: true, format: "esm" },
  ],
  plugins: [
    typescript({
      transformers: {
        before: [{ type: "program", factory: transformPaths }],
        afterDeclarations: [{ type: "program", factory: transformPaths }],
      },
    }),
  ],
});

The true default import looks like this , when it should be the transformer function.

import test from "typescript-transform-paths"
console.log(test);
// {
//   register: [Getter],
//   nxTransformerPlugin: [Getter],
//   default: [Function: transformer]
// }

This also means that the types do not correlate (hence the jsdoc comment in my config) so you need to cast it to have nice dx.
I believe this happens because of the way esModuleInterop assigns "default" to the "exports" object though i am not sure.

Side note: For me this package did not work by just editing my tsconfig.json (as suggested in this project's readme), though i believe that it should have (i see no reason the rollup plugin cant use it), maybe that is related to this, as typescript cannot resolve this import. (Maybe the blocker to #134?)

A fix to allow for easier programmatic usage is to include the transformer (and other things, why not) as a named export along the default export, this way the type would match and people could use it this way.

A overall fix would be to figure out a better way to transpile this package to both esm and cjs (rollup?) and therefore not having to rely on esModuleInterop.

I could attempt a PR if any of these options are desirable 👍

[danielpza]

Hey @mastondzn

A fix to allow for easier programmatic usage is to include the transformer (and other things, why not) as a named export along the default export, this way the type would match and people could use it this way.
I could attempt a PR if any of these options are desirable 👍

Sure, go for it 👍