Double Typescript compilation

[hatton]

Using cosmiconfig-typescript-loader 4.3.0, my cosmic config setup has

const cosmic = Cosmic.cosmiconfig("docu-notion", {
      loaders: {
        ".ts": TypeScriptLoader(),
      },
      searchPlaces: [`docu-notion.config.ts`],
    });

In the same project, as a test, I have docu-notion.config.ts:

import {
  IDocuNotionConfig,
  IPlugin,
  NotionBlock,
} from "./dist/config/configuration";
import { verbose } from "./dist/log";

const dummyBlockModifier: IPlugin = {
  name: "dummyBlockModifier",

  notionBlockModifications: [
    {
      modify: (block: NotionBlock) => {
        verbose("dummyBlockModifier was called");
      },
    },
  ],
};

export const config: IDocuNotionConfig = {
  plugins: [dummyBlockModifier],
};

But at runtime, when I run my project using ts-node on my index.ts, I get

TypeScriptLoader failed to compile TypeScript:
docu-notion.config.ts:9:22 - error TS7006: Parameter 'block' implicitly has an 'any' type.

9             modify: (block) => {
                       ~~~~~
docu-notion.config.ts:10:18 - error TS2695: Left side of comma operator is unused and has no side effects.

Notice, for example, that the original had a type on block, but here in the error, it as if the typescript annotations were stripped away.

Any chance someone can see what I'm doing wrong here? If not I can work on a minimal repro.

Thanks!

[Codex-]

Hmmm I can't seem to reproduce this locally, can you please create a minimal repro? 🙏

[hatton]

OK, here is a minimal repro.

The key is that this won't happen if the tsconfig does not have strict: true. I would think that the problem still happens, but typescript doesn't complain about it.

Thanks for looking into this!

[hatton]

We looked into this some more, and what is happening is a known bug in ts-node: Avoid double-transformation of a file when multiple ts-node hooks are registered. That is, in the repro, we have

   "scripts": {
    "start": "ts-node index.ts"
  },

and so that registers one ts-node, and then this loader registers another one, leading to double compilation. From that report, I don't see a workaround that cosmicconfig-typescript-loader can use to avoid this. Instead, clients will need to not use ts-node when running projects that using a library that uses this loader. Obviously this is a pretty fragile environment, but not your fault and nothing you can do about.

[hatton]

Unless you can use tsc instead of ts-node? https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API, e.g.

let result = ts.transpileModule(source, { compilerOptions: { module: ts.ModuleKind.CommonJS }});

[Codex-]

Well, that's a pain, I'd rather not use ts-node if I can avoid it anyway so I'll look into using TS directly. Less dependencies would be nice, and imposing ts-node on consumers is kind of not ideal

[Codex-]

I've had a brief look this morning and transpiling the source passed in works a treat, except that this method means that there is no assertion of the type system. I'll look into it more when I can, but I'm fairly swamped at the moment 😔
Happy to look or collaborate on a PR, or if you're okay with giving it some time I'll try look properly on Monday

[hatton]

Thanks. For now I've switched to using TSC on the project, so that this is the only ts-node in play.