[pnpm] Error 2742 The inferred type of xxx cannot be named

[vjau]

With same code, just replacing tsc with tsgo gives me multiple TS 2742 errors like these

error TS2742: The inferred type of 'router' cannot be named without a reference to '../../node_modules/@trpc/server/dist/unstable-core-do-not-import.js'. This is likely not portable. A type annotation is necessary.

Repro with instructions https://github.com/vjau/tsgo-error

[vjau]

20250610 doesn't error anymore with npm. But it still errors with a pnpm project. I updated the repro accordingly.

[bompi88]

Can confirm that it still happens with a pnpm project.

[dougludlow]

Seeing the same thing in a react project that also uses pnpm:

The inferred type of 'XXX' cannot be named without a reference to '.pnpm/@[email protected]/node_modules/@types/react/jsx-runtime'. This is likely not portable. A type annotation is necessary. ts(2742)

[RohinBhargava]

+1; note: as a temporary workaround, I could export types from the upstream package and this satisfied pnpm tsgo. A more native solution would be much better, though!

[vjau]

I removed Fastify, which was not needed for the reproduction.

[tmm1]

Hitting this too in a pnpm project.

The missing code is:

https://github.com/microsoft/typescript-go/blob/c5ec8120c938713e888db4955acb4975564fa10d/internal/modulespecifiers/specifiers.go#L235-L237

https://github.com/microsoft/typescript-go/blob/c5ec8120c938713e888db4955acb4975564fa10d/internal/compiler/knownsymlinks.go#L38-L44

https://github.com/microsoft/typescript-go/blob/c5ec8120c938713e888db4955acb4975564fa10d/internal/modulespecifiers/types.go#L49

[dBianchii]

I am getting this with pnpm:

[vjau]

I have hope the WIP PR https://github.com/microsoft/typescript-go/pull/1348 will fix this. I maybe completely wrong though 🤷

[safareli]

is there any short term workaround for this?

[RohinBhargava]

I've found you can directly import from the package, and the module resolution takes care of the errors for me. It is annoying to create this "shim", however.

[Ecksters]

We're also using a pnpm monorepo, getting this when switching to tsgo:

src/validateContext.ts(23,14): error TS2742: The inferred type of 'getContextHeaders' cannot be named without a reference to '.pnpm/@[email protected]/node_modules/@types/express-serve-static-core'. This is likely not portable. A type annotation is necessary.

src/validateContext.ts(23,14): error TS2742: The inferred type of 'getContextHeaders' cannot be named without a reference to '.pnpm/@[email protected]/node_modules/@types/qs'. This is likely not portable. A type annotation is necessary.

src/validateContext.ts(43,14): error TS2742: The inferred type of 'createReqContext' cannot be named without a reference to '.pnpm/@[email protected]/node_modules/@types/express-serve-static-core'. This is likely not portable. A type annotation is necessary.

src/validateContext.ts(43,14): error TS2742: The inferred type of 'createReqContext' cannot be named without a reference to '.pnpm/@[email protected]/node_modules/@types/qs'. This is likely not portable. A type annotation is necessary.

Imports in that file look like:

import { Request, Response, NextFunction } from 'express';
import { DbID, ReservedSessionUserId, ValidAny } from '@my-company/shared-types/common.js';
import {
  DbServiceRequestSource,
} from '@my-company/shared-types/dbService/utils.js'; // importing this also infers the global express declaration type
import { RESPONSE } from '@my-company/shared-utils/response.js';
import { includes, isEmpty, pick } from 'lodash-es';

And the main function in question:

export const getContextHeaders = (req: Request) => {
  const requestedFrom = req.get('x-requested-from') as DbServiceRequestSource;
  const profileId = req.get('x-profile-id');
  const userId = req.get('x-user-id');
  const accountId = req.get('x-account-id');

  return {
    requestedFrom,
    profileId,
    userId,
    accountId,
  };
};

DbServiceRequestSource is being used both as a value enum elsewhere in the file, and as a type enum here. We've gotten these errors before with tsc, and we usually resolve them by just hardcoding the return type of the function. My typical experience has been that they happen when you use enum types mixed with their value types. Seems like there's some kind of caching mechanism that when the regular type is used, you get a reference through the node_modules path, but if you only use the type then it properly references it through the monorepo, and we don't get this error.

Perhaps the silly part about this is if I literally just copy-paste the inferred type from the function and explicitly define it as the return type, it builds without complaint.

Unfortunately, it still won't let me build my project, because then I get hundreds of:

src/models/builders/chartBuilderConfig/PercentChartBuilderConfig.model.ts(36,13): error TS2742: The inferred type of '_validator' cannot be named without a reference to '.pnpm/[email protected]/node_modules/zod'. This is likely not portable. A type annotation is necessary.

and

src/models/transform/sort/Sort.model.ts(28,13): error TS2742: The inferred type of '_validator' cannot be named without a reference to '.pnpm/[email protected]/node_modules/zod/v4/core'. This is likely not portable. A type annotation is necessary.

Across our various files.

[justinbhopper]

I've found you can directly import from the package, and the module resolution takes care of the errors for me. It is annoying to create this "shim", however.

@RohinBhargava Do you mind giving a short illustration of what you mean by directly importing?

[RohinBhargava]

Totally: check out https://github.com/forklaunch/forklaunch-js/blob/f62ca5f3bbfc0a5095b49994143cbf4d32cac15c/framework/e2e-tests/servers/express-zod.ts#L408. Here, I import subdeps that I need and the errors disappear. Let me know if this works for you!

[spinda]

I'm currently using node-linker=hoisted to get around this, since that was the workaround when this bug was present in the original TypeScript. It also requires manually patching the pnpm-lock.yaml every time dependencies change to ensure that all workspace packages are referenced with link: versions instead of file: versions. FWIW, this is the one thing holding us back from full tsgo adoption currently, since that's a lot to inflict on the rest of the team.

[nirweiner2]

This is a blocker from our side as well... Watching..

[Ecksters]

I wanted to share here, we figured out that for our errors, we don't even need to do import * or anything like that, we're now doing:

import type {} from '@company-name/shared-types/common.js';

Swapping out the path for whichever path the error saying may not be portable says it depends on, and it fixes the type may not be portable errors, by getting the TypeScript resolution to use the path through the monorepo, instead of the cached path through node_modules that it had used previously when looking up the enum.

That resolves issues with imports within our own monorepo, but the TSGo-specific errors around imports in node_modules are still eluding us.

[MrBlackGhostt]

tyr to replace the path @Ecksters but it still shows to me The inferred type of 'router2' cannot be named without a reference to '.pnpm/@[email protected]/node_modules/@types/express-serve-static-core'. This is likely not portable. A type annotation is necessary.ts(2742)

[MrBlackGhostt]

My error got solve by explicit give the type annotation export const router: Router = Express.Router(); As the type system can't export somehow from the type the above path is given

[codingthat]

On one monorepo using bun 1.3.1, tsgo --noEmit from @typescript/[email protected] gives dozens of TS2742 errors, whereas tsc --noEmit from [email protected] runs clean.

[vjau]

On one project, tsgo --noEmit from @typescript/[email protected] gives dozens of TS2742 errors, whereas tsc --noEmit from [email protected] runs clean.

Yes, that's the problem. The thing is, the code they have to port is very complicated, i fear nobody is understanding it anymore, so this get put on the back of the todo list.

[dbartholomae]

For me, the ability to just turn off this error, would be enough to be able to use tsgo throughout my project. The error isn't meaningful in my context even without this false positives.

[jakebailey]

What situation are you running this in where the error does not matter? Do you just not use your code outside of your checkout?

[dbartholomae]

I'm writing application code, not library code: I don't care whether code might not be portable, just whether it is portable, and if it isn't, I'll anyways get errors on the consuming side, so I don't need this warning on the producing side.

[richburdon]

For me, the ability to just turn off this error, would be enough to be able to use tsgo throughout my project. The error isn't meaningful in my context even without this false positives.

@dbartholomae I've worked around this by configuring my settings as below and work in zen mode since i wasn't able to find a setting to disable these toasts. not ideal since you have to do this manually every time you startup.

  "zenMode.silentNotifications": true,
  "zenMode.fullScreen": false,
  "zenMode.centerLayout": false,
  "zenMode.hideActivityBar": false,
  "zenMode.hideStatusBar": false,
  "zenMode.hideLineNumbers": false

[dbartholomae]

Thanks, but I'm not using VSCode, and this wouldn't prevent CI from failing when it checks TypeScript

[colelawrence]

I am experiencing the same issue here, but with bun. I suspect it is the same issue, but I'm just hoping that if there is some special initial fix for .pnpm symlinked node_modules, that ./node_modules/.bun/ will be fixed here as well.

I would also be perfectly happy to have the option to make this specific error not fail my process, since I'm also in application code.

packages/codelinks/src/vite/mod.ts:7:7 - error TS2742: The inferred type of 'codelinksPlugin' cannot be named without a reference to '.bun/[email protected]/node_modules/vite'. This is likely not portable. A type annotation is necessary.

7 const codelinksPlugin = unplugin.vite;
        ~~~~~~~~~~~~~~~

apps/server/src/__e2e_tests__/helpers/server-test-harness-base.test-helpers.ts:17:14 - error TS2742: The inferred type of 'createServerTestHarnessBase' cannot be named without a reference to '.bun/[email protected]/node_modules/effect/Brand'. This is likely not portable. A type annotation is necessary.

17 export const createServerTestHarnessBase = (
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~

apps/server/src/__e2e_tests__/helpers/server-test-harness-base.test-helpers.ts:17:14 - error TS2742: The inferred type of 'createServerTestHarnessBase' cannot be named without a reference to '.bun/[email protected]/node_modules/effect/Context'. This is likely not portable. A type annotation is necessary.

17 export const createServerTestHarnessBase = (
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~
...

[JCMais]

#1902 will fix this for those that are having this error due to pnpm or similar package managers that use symlinks.

[sebastienbarre]

Great, thx. Are these changes pushed to a NPM version of tsgo every night?

UPDATE: thanks for the work, it does indeed solve the pnpm issues I was experiencing.

[jakebailey]

Yes.

[samhh]

I've updated our (pnpm) monorepo to 7.0.0-dev.20251204.1 and, though I'm seeing fewer of these errors, there are still many of them giving 200 total type errors where tsc has none. I'm assuming this version includes the closing PR as it was only published a few hours ago?