rollup-plugin-typescript2: a TypeScript plugin that reports errors

The reason this plugin exists

rollup-plugin-typescript2 is a Rollup plugin for TypeScript with compiler errors, and the README says the thing that makes it different in one sentence: this version is somewhat slower than the original, but it will print out TypeScript syntactic and semantic diagnostic messages, which the README calls the main reason for using TypeScript after all.

That framing is the whole design. A build pipeline that uses TypeScript as a transpiler and never checks the types will happily bundle code with type errors in it, and the first person to find out is usually a user of the library. This plugin makes the type check part of the build, and the cost of that is time, because the compiler now has to do the work it was being used to avoid.

The lineage is documented, and it explains the shape of the project. It is a rewrite of the original rollup-plugin-typescript, taken from the v0.8.1 branch, and it started by borrowing from a fork by another author. So this is not a new idea in 2026, it is a maintained continuation of a plugin that several projects depended on, and the question the README answers is whether the maintained continuation is worth the slowdown for a project that has an existing TypeScript setup.

The releases are 0.35.0 on 2023-06-23, 0.36.0 on 2023-09-27 and 0.37.0 on 2026-03-30, with the last push on 2026-07-23. The gap between the two older releases and the recent one is the story of the project: it survived, and then somebody came back to it.

Install and configure

Installation is a dev dependency alongside TypeScript itself and the tslib runtime helpers:

# with npm
npm install rollup-plugin-typescript2 typescript tslib --save-dev
# with yarn
yarn add rollup-plugin-typescript2 typescript tslib --dev

The configuration in rollup.config.js is three lines:

// rollup.config.js
import typescript from 'rollup-plugin-typescript2';

export default {
	input: './main.ts',

	plugins: [
		typescript(/*{ plugin options }*/)
	]
}

The important property, and the one that makes this plugin pleasant to use, is that it inherits all compiler options and file lists from your tsconfig.json file. You do not restate your compiler options in the Rollup config, so the file that already describes your project keeps doing so, and the plugin and the type checker cannot drift apart.

If your tsconfig has another name or another relative path from the root directory, there are options for it: tsconfigDefaults, tsconfig and tsconfigOverride. The tsconfig option sets the path, and it defaults to trying to load ./tsconfig.json, without failing if the file is missing, unless the value is explicitly set. And because the config is per plugin instance, this also allows for passing in different tsconfig files depending on your build target, which is how you build a library and its examples with different settings in one repository.

The rest of the options are documented individually, and several of them exist only to work around a specific issue.

The compiler options the plugin takes over

The section headed Some compiler options are forced is the most important part of the README for anyone configuring the plugin, because these settings are applied on top of your tsconfig whether you asked for them or not.

The list is short and each entry links to the issue that explains it. noEmitHelpers is forced to false and importHelpers to true, which together mean the TypeScript helper functions are imported from tslib rather than inlined, which is why tslib is a dependency of the install command. noResolve and noEmit are forced to false, with the note that Rollup controls emit. noEmitOnError is forced to false for the same reason, with a pointer to the abortOnError plugin option, which is the real switch for whether a type error fails the build.

inlineSourceMap is forced to false, and outDir is forced to a placeholder directory inside the cache root, because TypeScript's own output settings fight with Rollup's. declarationDir is set to Rollup's output.file or output.dir, unless useTsconfigDeclarationDir is true in the plugin options. And allowNonTsExtensions is forced to true, so that other plugins in the chain can generate TypeScript, with a note to update the plugin's include filter to pick those files up.

The practical advice that follows the forced options is to read them as a set rather than as a list of quirks, because they all point the same way. The plugin is the thing that emits code, so TypeScript's emit-related options are neutralised and Rollup's own settings are respected instead. The two exceptions are the ones you can change, and they are the two you would want to know about: abortOnError for the type check, and useTsconfigDeclarationDir if your declaration output is not where Rollup puts it.

module and moduleResolution, the two settings that cause trouble

Two compiler options have more than one compatible value, and both are places where a project can fail in a way that looks like a plugin bug.

The first is module, which defaults to ES2015. The other valid values are ES2020, ES2022 and ESNext, and ESNext is required for dynamic imports.

The second is moduleResolution, which defaults to node10, the same as node, unless the tsconfig specifies a value. The other valid values are node16, nodenext and bundler, and the README marks them as valid but mostly untested. If in doubt, use node10.

And then the trap. The classic resolution mode is deprecated and was changed to node10, and the README says it also breaks this plugin, with two issue links. So a project that has been carrying a classic setting from an old tsconfig will fail with this plugin in a way that has nothing to do with the plugin's own code.

There is one more option in this group that needs extra work rather than a choice. allowJs lets TypeScript process JavaScript files as well, and if you use it you are told to modify the plugin's include option to add the JavaScript globs, and you might also want to exclude node_modules, with the note that including it can slow down the build significantly.

The reason that last warning is worth repeating is that it is the same problem in a different form. The default include is a broad set of TypeScript globs, and once you add JavaScript to it, the plugin will start reading your dependency tree, and the type check that makes the plugin worth its slowdown becomes the thing that makes it slow.

Plugin order, and the Babel extension trap

The compatibility section is short and saves a lot of time.

The node resolve plugin must be before rollup-plugin-typescript2 in the plugin list, especially when the browser option is used. The reason is ordering of work rather than a bug: if resolution has not happened when the type check runs, the compiler sees a different set of imports than the bundler will.

The Babel plugin has a different kind of problem. It transpiles code but does not change file extensions, and by default it only looks at code with a list of extensions that does not include TypeScript. The workaround is to add the TypeScript extensions to that list:

// ...
import { DEFAULT_EXTENSIONS } from '@babel/core';
// ...
	babel({
		extensions: [
			...DEFAULT_EXTENSIONS,
			'.ts',
			'.tsx'
		]
	}),
// ...

The commonjs plugin has its own note, pointing at the rollupCommonJSResolveHack option, which is a plugin option for the same family of problem: the commonjs transform and the TypeScript check need to see the same resolution the bundler will use.

Taken together, the compatibility rules say that the type check is only as good as the resolution the bundler sees. Every one of these workarounds is about making the compiler's view of the module graph match the bundler's, which is a general lesson about running a type checker inside a bundler.

Options for the cache, the diagnostics and the config merge

The plugin options list is long, and the ones that matter day to day are the diagnostics and the cache.

The check option defaults to true, and setting it to false avoids doing any diagnostic checks on the code, which the README notes is sometimes referred to as transpileOnly by other TypeScript integrations. That is the escape hatch if the slowdown is unacceptable, at the price of the feature the plugin exists for.

Verbosity defaults to 1, with 0 for error, 1 for warning, 2 for info and 3 for debug. The advice for the tsconfig merge options is to increase verbosity to 3 and look for parsed tsconfig if you get something unexpected, which is a useful instruction because the merge of three configuration layers is where surprises live.

The cache is controlled by three options. clean, defaulting to false, disables the cache and does a clean build, and it also wipes any existing cache. cacheRoot is the path to the cache and defaults to a folder in node_modules, at node_modules/.cache/rollup-plugin-typescript2. And the file selection is explicit: include defaults to the TypeScript globs, meaning .ts, .tsx, .cts and .mts files, and exclude defaults to the declaration file globs, so type definitions are not compiled.

The tsconfig merging deserves a note of its own, because the order is not obvious. The final config passed to TypeScript is the result of the values in tsconfigDefaults replaced by the values in the loaded tsconfig.json, replaced by the values in tsconfigOverride, and then replaced by the forced compiler option overrides on top of that. The merge is a deep merge, where objects are merged, arrays are merged by index, and primitives are replaced. The README's own advice is to try to minimize the usage of defaults and overrides and keep everything in the tsconfig.json file, since tsconfigs can themselves be chained with extends, so save some turtles.

The last option in the visible list, abortOnError, defaults to true, and it is the one that turns the type error into a build failure.

The package, and the state of the project

The package manifest describes a small, well-behaved distribution. The name is rollup-plugin-typescript2 at version 0.37.1, with the description Integration between Rollup and TypeScript, now with errors. It ships three entry points, a CommonJS build as the main field, an ES module build for the module and jsnext:main fields, and the type declarations at dist/index.d.ts, and the published files list contains only dist.

The runtime dependencies are five and all of them are small utilities: the Rollup plugin utilities, find-cache-dir, fs-extra, semver and tslib. The peer dependencies are Rollup from 1.26.3 upwards and TypeScript from 2.4.0 upwards, which is a wide range and one of the reasons the plugin is still viable in older projects.

The development dependencies show how the plugin tests itself, and the arrangement is unusual and interesting. The plugin builds itself with Rollup, using a base config, a config for the normal build and a separate self config used by the watch and build-self scripts, so the plugin is bundled by the same tool it bundles for, which is a good way to catch a broken build. The test runner is Jest, with a jest.config.js at the root and a __tests__/ directory, and there are separate tsconfig files for the base configuration, the project itself and the tests.

The repository root also has an .eslintrc.cjs, a CHANGELOG.md, a CONTRIBUTING.md, a .gitattributes and a .editorconfig, plus the dist/ directory checked in, which is consistent with a package that publishes its own build output rather than building on install.

As for maintenance, the release history of 0.35.0, 0.36.0 and 0.37.0 shows a project that went quiet for a while and came back, and the last push on 2026-07-23 says that it is still being worked on.

Editorial conclusion

Adopt rollup-plugin-typescript2 if you build a TypeScript library with Rollup and want type errors to fail the build, because that is the one thing the plugin it replaced did not do. Do not adopt it if you only need to strip types, because the check option can be turned off and then you are paying for a slower plugin with no benefit, or if your build depends on a TypeScript version below 2.4. Before you configure it, read the forced options list, because the plugin overrides several compiler options regardless of your tsconfig, and if you use allowJs, adjust the include filter and exclude node_modules yourself, since the default configuration will compile your whole dependency tree.

Frequently asked questions

Official sources

1. ezolenko/rollup-plugin-typescript2 on GitHub
2. Issues
3. License: MIT
4. README
5. Releases