Using ES modules with TypeScript, Webpack, and Jasmine: A comprehensive guide

Question

Using ES modules with TypeScript, Webpack, and Jasmine: A comprehensive guide

My Package Workflow

For my personal projects, I have a consistent structure for the packages I create and reuse. In production, I write these packages in TypeScript and compile them to JavaScript using `tsc` before publishing them to npm. This allows me to seamlessly use them in my other projects. I also run tests on these packages using Jasmine.

During development, I utilize Webpack with `ts-loader` to compile the TypeScript code in a way that supports running example scripts in a browser. Although the projects consuming these packages recognize them as JavaScript files only (due to pre-compilation before publishing), I still use Webpack for consistency.

Uniformly using ES module syntax in all contexts is vital to me. This avoids the hassle of switching between CommonJS for Node.js and ES module syntax for browsers. To ensure this consistency in Jasmine, I have configured my `jasmine.json` file with `"jsLoader": "import"`.

However, I am facing an issue with writing import statements, specifically how to specify file extensions to work seamlessly across different scenarios while developing these packages.

No File Extension Approach

When using `import { foo } from './foo';` in TypeScript, the Node module resolution assumes the file as `foo.ts`. Webpack's `resolve` configuration, specifying `extensions: ['.js', '.ts']`, also aligns with TypeScript's behavior in resolving imports with no file extensions.

Unfortunately, while this approach works for TypeScript and Webpack, running Jasmine tests with `import` without file extensions results in unresolved module errors.

Using .js File Extension Approach

Alternatively, including the `.js` file extension in imports like `import { foo } from './foo.js';` is supported in TypeScript since version 2. This allows successful compilation with `tsc` and resolves Jasmine tests as well.

However, Webpack struggles to interpret `./foo.js` as `./foo.ts`. This hinders building the code for showcasing examples in the browser.

.js Extension with Webpack Aliases

To address this limitation, I resorted to using Webpack's `resolve.alias` configuration to explicitly map `./foo.js` to `./foo.ts`. While this workaround works, it feels cumbersome and lacks scalability.

Is there a better, more optimal solution to handle file extensions in import statements across TypeScript, Webpack, and Jasmine without the need for numerous aliases?

typescript webpack jasmine ts-loader

Answer 1

Answer №1

Latest Update: 2022-10-20

Webpack v5.74.0 was officially released in July 2022, introducing a new feature called resolve.extensionAlias. This feature addresses the issue at hand without the need for additional plugins.

For instance, with the following configuration:

resolve: {
    extensionAlias: {
        '.js': ['.ts', '.js'],
    },
}

Previous Solution: 2021-09-07

Credit goes to amosq's insight on a related question, which provided a solution to the problem originally raised.

While Jasmine may have appeared to be a factor, the true crux of the matter lay in the ES Module resolution attempt within the setup. The issue stemmed from Webpack's module resolution inability to mimic TypeScript's module resolution behavior, specifically the treatment of *.js paths as potentially leading to *.ts files.

Thanks to amosq's recommendation, resolution came in the form of a Webpack resolver plugin: resolve-typescript-plugin

Although the plugin's instructions primarily catered to CommonJS syntax, I managed to incorporate it into my ES Module-based Webpack configuration as follows:

import resolveTypeScriptPluginModule from 'resolve-typescript-plugin';
const ResolveTypeScriptPlugin = resolveTypeScriptPluginModule.default;

const config = {
    // ...
    resolve: {
        fullySpecified: true,
        plugins: [new ResolveTypeScriptPlugin()],
        // ...
    },
    // ...
};

This setup successfully enabled the usage of Webpack alongside ts-loader for compiling TypeScript files featuring *.js import statements, operating harmoniously with my existing tsc workflow. Consequently, the workaround involving Webpack aliases outlined in my initial query became obsolete.

Answer 2

Latest Update: 2022-10-20

Webpack v5.74.0 was officially released in July 2022, introducing a new feature called resolve.extensionAlias. This feature addresses the issue at hand without the need for additional plugins.

For instance, with the following configuration:

resolve: {
    extensionAlias: {
        '.js': ['.ts', '.js'],
    },
}

Previous Solution: 2021-09-07

Credit goes to amosq's insight on a related question, which provided a solution to the problem originally raised.

While Jasmine may have appeared to be a factor, the true crux of the matter lay in the ES Module resolution attempt within the setup. The issue stemmed from Webpack's module resolution inability to mimic TypeScript's module resolution behavior, specifically the treatment of *.js paths as potentially leading to *.ts files.

Thanks to amosq's recommendation, resolution came in the form of a Webpack resolver plugin: resolve-typescript-plugin

Although the plugin's instructions primarily catered to CommonJS syntax, I managed to incorporate it into my ES Module-based Webpack configuration as follows:

import resolveTypeScriptPluginModule from 'resolve-typescript-plugin';
const ResolveTypeScriptPlugin = resolveTypeScriptPluginModule.default;

const config = {
    // ...
    resolve: {
        fullySpecified: true,
        plugins: [new ResolveTypeScriptPlugin()],
        // ...
    },
    // ...
};

This setup successfully enabled the usage of Webpack alongside ts-loader for compiling TypeScript files featuring *.js import statements, operating harmoniously with my existing tsc workflow. Consequently, the workaround involving Webpack aliases outlined in my initial query became obsolete.

Using ES modules with TypeScript, Webpack, and Jasmine: A comprehensive guide

My Package Workflow

No File Extension Approach

Using .js File Extension Approach

.js Extension with Webpack Aliases

Answer №1

Latest Update: 2022-10-20

Previous Solution: 2021-09-07

Similar questions

Having trouble setting State in React with Typescript?

Stop MatDialog instance from destroying

What is the best way to handle API requests within an Angular component?

What steps do I need to take to integrate FontAwesome with the vue-cli webpack-simple template?

Is there a way to prevent certain folders that have .vue files from being included in the VueJS build process?

Is it possible for Webpack to compile a Vue template using the coffee-loader?

Ready to Opt-Out in RxJS 6?

Using TypeScript with Angular UI Router for managing nested named views in the application

When attempting to specify the path in the angular.json file, Angular encounters difficulty accessing Bootstrap from the node_modules directory

What is the best way to implement a nested fetch call?

What is the best way to generate an object in TypeScript with a variety of fields as well as specific fields and methods?

Adding a timestamp to an array in Angular/Typescript services

What distinguishes ReadonlyArray from the declaration "readonly arr: T[]"?

Adding JavaScript files into Templates or HTML using webpack

Can you explain the true meaning behind this specific type definition?

What is the best way to call a method within a TypeScript class using its name as a string while already inside the class itself?

Navigating with the Angular router leads to an unexpected destination: "mat-radio-group-0=true"

What is the best way to list the choices associated with a specific category?

Error encountered in Jest mockImplementation: Incompatible types - 'string[]' cannot be assigned to 'Cat[]' type

The TypeScript error ts2322 occurs when using a generic constraint that involves keyof T and a