TS incorrectly flags a side effect-only import as TS5097 (An import path can only end with a '.ts' extension...) in `--watch` mode

[Aarononomous]

🔎 Search Terms

"TS5097", "allowImportingTsExtensions", "noEmit", "watch", "side effect", "import"

🕗 Version & Regression Information

• This changed in commit or PR 89e928e

⏯ Playground Link

No response

💻 Code

When importing a .ts file strictly for side effects,

import './a.ts';

I expect that this will be accepted by the typechecker. In fact, even if a.ts didn't exist, this would still be valid TS, see #50394 (comment) for a motivating example.

Typechecking with --noEmit validates this without error.

Typechecking with --watch gives me error TS5097: An import path can only end with a '.ts' extension when 'allowImportingTsExtensions' is enabled.

a.ts

console.log("I'm a side effect!");

b.ts

import './a.ts';

tsconfig.json

{}

🙁 Actual behavior

% npx tsc --noEmit # no output. Valid!
% npx tsc --watch
[5:54:03 PM] Starting compilation in watch mode...

b.ts:1:8 - error TS5097: An import path can only end with a '.ts' extension when 'allowImportingTsExtensions' is enabled.

1 import './a.ts';
         ~~~~~~~~

[5:54:04 PM] Found 1 error. Watching for file changes.

I shouldn't see a new error only in --watch mode.

🙂 Expected behavior

% npx tsc --noEmit # no output. Valid.
% npx tsc --watch
[5:54:37 PM] File change detected. Starting incremental compilation...

[5:54:37 PM] Found 0 errors. Watching for file changes.

Additional information about the issue

Workaround: // @ts-ignore before the import.

[Andarist]

accidentally-ish one of my recent PRs fixes this: #58668 , maybe @jakebailey could create a TS build of that PR so you could fully confirm that

[fatcerberus]

@Andarist And you wanted to make this an error across the board... tsk tsk 😉

[Andarist]

I didn't say I'm happy I fixed this, did I?

[Andarist]

I really wonder why @Aarononomous is doing this in his code though. What's the reason behind importing a side-effectful .ts without enabling allowImportingTsExtensions? 🤔

[Aarononomous]

I really wonder why @Aarononomous is doing this in his code though. What's the reason behind importing a side-effectful .ts without enabling allowImportingTsExtensions? 🤔

I'm working in a multitenant codebase. We put platform-specific code in *.platformName.ts files, adding the platform name as an extension. Then we have a webpack resolver configured to look for platform files preferentially,

resolve: {
  extensions: [
    ...
    `.${CONFIG.platform}.ts`,
    `.${CONFIG.platform}.tsx`,
    '.ts',
    '.tsx',
    ...

so that when we build for, say, platformX and see import './a', we first look for a file at ./a.platformX.ts, then ./a.ts. This allows us to write all of our platform-specific code without runtime tests or compiler macros or whatever, neatly encapsulated in its own file.

So not only do we not want to allow ts extensions, we can't! Otherwise our whole multitenant resolver behavior falls apart.

The exception to this is in the multitenant files themselves, where we do sometimes want to import common code from the extensionless base files, e.g.

a.platformX.ts

// @ts-expect-error
// We need the full filename with extension here: otherwise there's a circular import
import { module as baseModule } from './a.ts';

// do something with baseModule...

export const module;

The 'allowImportingTsExtensions' error is expected when we import with a full filename. It's just when we only import for side effects from the base file that we see this inconsistency in --watch mode.

So the code example above is really more like

a.ts

window.__CONFIG__ = { ... };

a.platformX.ts

import './a.ts';

window.__CONFIG__.platformX = { ... };

[Andarist]

The use case makes sense but I think you could introduce some other convention for those base modules to avoid this problem altogether.

[Aarononomous]

@Andarist, what do you suggest?

If I put my side-effectful code in, say, a.base.ts, I'd still be calling it in a.ts, a.platformX.ts, etc. with

import 'a.base.ts';

[Andarist]

At that point, couldn't you import './a.base'? There would be no a.base.platformX.ts so it would eventually resolve to just a.base.ts.