What could be the reason behind TypeScript automatically appending .default to a global import declaration?

Question

What could be the reason behind TypeScript automatically appending .default to a global import declaration?

Having a global definition within an external library file named thing.d.ts:

declare var thing: ThingStatic;
export default thing;

Importing the npm module in TypeScript:

import thing from 'thing';
...
thing.functionOnThing();

After transpiling the TypeScript (with ES6 target), it results in:

const thing_1 = require("thing");
...
thing_1.default.functionOnThing();

Leading to the error message:

Cannot read property 'functionOnThing' of undefined

The confusion lies in why TypeScript is inserting .default between thing_1 and functionOnThing().

It's important to note that there is no default property defined on ThingStatic, nor on the underlying JS object specified in the .d.ts file.

Understanding why TypeScript includes this property and how to prevent it is crucial. Can anyone provide insight on fixing this issue?

typescript ecmascript-6 typescript-typings

Answer 1

Answer №1

import item from 'item';

This snippet indicates "import the default export from the module 'item' and assign it to the variable name item".

TypeScript complies with your instruction and references the default property of the module object.

You likely intended to express:

import * as item from 'item';

Answer 2

import item from 'item';

This snippet indicates "import the default export from the module 'item' and assign it to the variable name item".

TypeScript complies with your instruction and references the default property of the module object.

You likely intended to express:

import * as item from 'item';

Answer 3

Answer №2

It seems like there is a bug related to global TypeScript definitions and the use of "module": "commonjs" in the tsconfig.json.

You have two options: either stick with global TypeScript definitions and combine all your output into a single file, or switch to using modules and importing them directly.

The issue here stems from the fact that require returns the module context, and the name of the default doesn't matter - it always defaults to default...

declare var thing: ThingStatic;
export thing; // Explicit export for thing
export default thing; // Default export for thing

Now when you use require, it will return this context. With commonjs modules:

import module from 'thing';
var thing = module.default; // Retrieves the default export
var alsoThing = module.thing; // Retrieves the named export

However, I've personally experienced inconsistencies with this method, so I switched to using ES6 modules instead:

import thing from './thing'; // Imports the default export
import { thing } from './thing'; // Imports the named export
const thing = (await import('path/to/thing.js')).default; // Dynamically imports

Answer 4

It seems like there is a bug related to global TypeScript definitions and the use of "module": "commonjs" in the tsconfig.json.

You have two options: either stick with global TypeScript definitions and combine all your output into a single file, or switch to using modules and importing them directly.

The issue here stems from the fact that require returns the module context, and the name of the default doesn't matter - it always defaults to default...

declare var thing: ThingStatic;
export thing; // Explicit export for thing
export default thing; // Default export for thing

Now when you use require, it will return this context. With commonjs modules:

import module from 'thing';
var thing = module.default; // Retrieves the default export
var alsoThing = module.thing; // Retrieves the named export

However, I've personally experienced inconsistencies with this method, so I switched to using ES6 modules instead:

import thing from './thing'; // Imports the default export
import { thing } from './thing'; // Imports the named export
const thing = (await import('path/to/thing.js')).default; // Dynamically imports

What could be the reason behind TypeScript automatically appending .default to a global import declaration?

Answer №1

Answer №2

Similar questions

The declared type 'never[]' cannot be assigned to type 'never'. This issue is identified as TS2322 when attempting to pass the value of ContextProvider using the createContext Hook

Despite awaiting them, promises are not resolving synchronously

The specified object '[object Object]' is not compatible with NgFor, which only supports binding to iterable data types like Arrays

Unlocking the capabilities of Chrome extensions using Angular 2 and TypeScript

Processing HTTP requests routed from Firebase Hosting to Cloud Functions

Why isn't the background-image displaying with the use of the url() function?

What is the best way to combine index signatures with established properties?

Exploring Manipulation of M:N Associations in Sequelize

Guidelines for creating a masterpage and details page layout in Angular 6

Steps for sending an image to Cloudinary using the fetch API

React Component - Element with an undefined value

Swapping the content of the API response with Angular 11 in the HTML

Error message in CodeSandBox with Angular: TypeError - The function html2canvas_1.default is not defined or recognized

Utilizing multiple page objects within a single method in Cypress JS

Book of Tales displaying Emotion Styling upon initial load only

Can I modify the cookie domain for NestJS SessionModule on a per-request basis?

Facing numerous "error TS1005" messages when performing a gulp build due to node_modules/@types/ [prop types] and [react] index.d.ts with SPFx Webpart

Issue with Pagination functionality when using Material-UI component is causing unexpected behavior

'The object of type '{}' does not support indexing with a 'string'

The SortKey<> function is ineffective, even though the individual types it uses work perfectly fine