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

[Andarist]

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

[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.

[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 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';