Anton Gilgur eab48a3951
fix: type-check included files missed by transform (type-only files) (#345)
* fix: type-check `include`d files missed by transform (type-only files)

- type-only files never get processed by Rollup as their imports are
  elided/removed by TS in the resulting compiled JS file
  - so, as a workaround, make sure that all files in the `tsconfig`
    `include` (i.e. in `parsedConfig.fileNames`) are also type-checked
    - note that this will not catch _all_ type-only imports, in
      particular if one is using `tsconfig` `files` (or in general _not_
      using glob patterns in `include`) -- this is just a workaround,
      that requires a separate fix
  - we do the same process for generating declarations for "missed"
    files right now in `_onwrite`, so basically do the same thing but
    for type-checking in `_ongenerate`

(_technically_ speaking, there could be full TS files
(i.e. _not_ type-only) that are in the `include` and weren't
transformed
- these would basically be independent TS files not part of the bundle
  that the user wanted type-checking and declarations for (as we
  _already_ generate declarations for those files))

* move misssed type-checking to `buildEnd` hook, remove declarations check

- `buildEnd` is a more correct place for it, since this does not generate any output files
  - (unlike the missed declarations)
  - and this means it's only called once per build, vs. once per output

- remove the check against the `declarations` dict as one can type-check without outputting declarations
  - i.e. if `declaration: false`; not the most common use-case for rpt2, but it is one

* add new checkedFiles Set to not duplicate type-checking

- since `parsedConfig.fileNames` could include files that were already checked during the `transform` hook
- and because `declarations` dict is empty when `declaration: false`, so can't check against that

* move checkedFiles.add to the beginning of typecheckFile

- because printing diagnostics can bail if the category was error
  - that can result in a file being type-checked but not added to checkedFiles

* wip: fuse _ongenerate functionality into buildEnd, _onwrite into generateBundle

- per ezolenko, the whole generateRound etc stuff was a workaround because the buildEnd hook actually _didn't exist_ before
  - so now that it does, we can use it to simplify some logic
  - no longer need `_ongenerate` as that should be in `buildEnd`, and no longer need `_onwrite` as it is the only thing called in `generateBundle`, so just combine them
  - importantly, `buildEnd` also occurs before output generation, so this ensures that type-checking still occurs even if `bundle.generate()` is not called

- also move the `walkTree` call to above the "missed" type-checking as it needs to come first
  - it does unconditional type-checking once per watch cycle, whereas "missed" only type-checks those that were, well, "missed"
  - so in order to not have duplication, make "missed" come after, when the `checkedFiles` Set has been filled by `walkTree` already

- and for simplification, just return early on error to match the current behavior
  - in the future, may want to print the error and continue type-checking other files
    - so that all type-check errors are reported, not just the first one

NOTE: this is WIP because the `cache.done()` call and the `!noErrors` message are incorrectly blocked behind the `pluginOptions.check` conditional right now
- `cache.done()` needs to be called regardless of check or error or not, i.e. in all scenarios
  - but ideally it should be called after all the type-checking here
- `!noErrors` should be logged regardless of check or not
  - and similarly, after the type-checking

* call `cache().done()` and `!noErrors` in check and non-check conditions

- instead of making a big `if` statement, decided to split out a `buildDone` function
  - to always call at the end of the input phase

- we can also move the `cache().done()` in `emitSkipped` into `buildEnd`, as `buildEnd` gets called when an error occurs as well
  - and this way we properly print for errors as well

- `buildDone` will have more usage in other PRs as well, so I figure it makes sense to split it out now as well

* use `RollupContext` for type-only files

- i.e. bail out when `abortOnError: true`, which `ConsoleContext` can't do
  - `ConsoleContext` is basically meant for everywhere `RollupContext` can't be used
    - which is effectively only in the `options` hook, per the Rollup docs: https://rollupjs.org/guide/en/#options

* add test for type-only file with type errors

- now that the integration tests exist, we can actually test this scenario

- refactor: give each test their own `onwarn` mock when necessary
  - while `restoreMocks` is set in the `jest.config.js`, Jest apparently has poor isolation of mocks: https://github.com/facebook/jest/issues/7136
    - if two tests ran in parallel, `onwarn` was getting results from both, screwing up the `toBeCalledTimes` number
  - couldn't get the syntax error to work with `toBeCalledTimes` either
    - if no mock is given, it _does_ print warnings, but if a mock is given, it doesn't print, yet isn't called?
      - I think the mock is getting screwed up by the error being thrown here; maybe improperly saved or something
2022-07-12 10:01:01 -06:00
2022-06-06 17:59:45 -06:00
2017-06-21 22:33:55 -06:00
2017-02-01 21:02:22 -07:00
2020-08-07 12:04:35 -06:00
2017-10-24 10:08:16 -06:00
2020-10-02 10:49:00 -06:00
2017-10-24 10:08:16 -06:00

rollup-plugin-typescript2

npm-version npm-monthly-downloads Node.js CI

Rollup plugin for typescript with compiler errors.

This is a rewrite of the original rollup-plugin-typescript, starting and borrowing from this fork.

This version is somewhat slower than the original, but it will print out TypeScript syntactic and semantic diagnostic messages (the main reason for using TypeScript after all).

Installation

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

Usage

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

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

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

This plugin inherits all compiler options and file lists from your tsconfig.json file. If your tsconfig has another name or another relative path from the root directory, see tsconfigDefaults, tsconfig, and tsconfigOverride options below. This also allows for passing in different tsconfig files depending on your build target.

Some compiler options are forced

  • noEmitHelpers: false
  • importHelpers: true
  • noResolve: false
  • noEmit: false (Rollup controls emit)
  • noEmitOnError: false (Rollup controls emit. See #254 and the abortOnError plugin option below)
  • inlineSourceMap: false (see #71)
  • outDir: ./placeholder in cache root (see #83 and Microsoft/TypeScript#24715)
  • declarationDir: Rollup's output.file or output.dir (unless useTsconfigDeclarationDir is true in the plugin options)
  • moduleResolution: node (classic is deprecated. It also breaks this plugin, see #12 and #14)
  • allowNonTsExtensions: true to let other plugins on the chain generate typescript; update plugin's include filter to pick them up (see #111)

Some compiler options have more than one compatible value

  • module: defaults to ES2015. Other valid values are ES2020 and ESNext (required for dynamic imports, see #54).

Some options need additional configuration on plugin side

  • allowJs: lets TypeScript process JS files as well. If you use it, modify this plugin's include option to add "*.js+(|x)", "**/*.js+(|x)" (might also want to exclude "**/node_modules/**/*", as it can slow down the build significantly).

Compatibility

@rollup/plugin-node-resolve

Must be before rollup-plugin-typescript2 in the plugin list, especially when the browser: true option is used (see #66).

@rollup/plugin-commonjs

See the explanation for rollupCommonJSResolveHack option below.

@rollup/plugin-babel

This plugin transpiles code, but doesn't change file extensions. @rollup/plugin-babel only looks at code with these extensions by default: .js,.jsx,.es6,.es,.mjs. To workaround this, add .ts and .tsx to its list of extensions.

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

See #108

Plugin options

  • cwd: string

    The current working directory. Defaults to process.cwd().

  • tsconfigDefaults: {}

    The object passed as tsconfigDefaults will be merged with the loaded tsconfig.json. The final config passed to TypeScript will be the result of values in tsconfigDefaults replaced by values in the loaded tsconfig.json, replaced by values in tsconfigOverride, and then replaced by forced compilerOptions overrides on top of that (see above).

    For simplicity and other tools' sake, try to minimize the usage of defaults and overrides and keep everything in a tsconfig.json file (tsconfigs can themselves be chained with extends, so save some turtles).

    let defaults = { compilerOptions: { declaration: true } };
    let override = { compilerOptions: { declaration: false } };
    
    // ...
    plugins: [
    	typescript({
    		tsconfigDefaults: defaults,
    		tsconfig: "tsconfig.json",
    		tsconfigOverride: override
    	})
    ]
    

    This is a deep merge: objects are merged, arrays are merged by index, primitives are replaced, etc. Increase verbosity to 3 and look for parsed tsconfig if you get something unexpected.

  • tsconfig: undefined

    Path to tsconfig.json. Set this if your tsconfig has another name or relative location from the project directory.

    By default, will try to load ./tsconfig.json, but will not fail if the file is missing, unless the value is explicitly set.

  • tsconfigOverride: {}

    See tsconfigDefaults.

  • check: true

    Set to false to avoid doing any diagnostic checks on the code. Setting to false is sometimes referred to as transpileOnly by other TypeScript integrations.

  • verbosity: 1

    • 0 -- Error
    • 1 -- Warning
    • 2 -- Info
    • 3 -- Debug
  • clean: false

    Set to true for clean build (wipes out cache on every build).

  • cacheRoot: node_modules/.cache/rollup-plugin-typescript2

    Path to cache. Defaults to a folder in node_modules.

  • include: [ "*.ts+(|x)", "**/*.ts+(|x)" ]

    By default passes all .ts files through typescript compiler.

  • exclude: [ "*.d.ts", "**/*.d.ts" ]

    But excludes type definitions.

  • abortOnError: true

    Bail out on first syntactic or semantic error. In some cases, setting this to false will result in an exception in Rollup itself (for example, unresolvable imports).

  • rollupCommonJSResolveHack: false

    Deprecated. OS native paths are now always used since 0.30.0 (see #251), so this no longer has any effect -- as if it is always true.

  • objectHashIgnoreUnknownHack: false

    The plugin uses your Rollup config as part of its cache key. object-hash is used to generate a hash, but it can have trouble with some uncommon types of elements. Setting this option to true will make object-hash ignore unknowns, at the cost of not invalidating the cache if ignored elements are changed.

    Only enable this option if you need it (e.g. if you get Error: Unknown object type "xxx") and make sure to run with clean: true once in a while and definitely before a release. (See #105 and #203)

  • useTsconfigDeclarationDir: false

    If true, declaration files will be emitted in the declarationDir given in the tsconfig. If false, declaration files will be placed inside the destination directory given in the Rollup configuration.

    Set to false if any other Rollup plugins need access to declaration files.

  • typescript: peerDependency

    If you'd like to use a different version of TS than the peerDependency, you can import a different TypeScript module and pass it in as typescript: require("path/to/other/typescript").

    You can also use an alternative TypeScript implementation, such as ttypescript, with this option.

    Must be TS 2.0+; things might break if the compiler interfaces changed enough from what the plugin was built against.

  • transformers: undefined

    experimental, TypeScript 2.4.1+

    Transformers will likely be available in tsconfig eventually, so this is not a stable interface (see Microsoft/TypeScript#14419).

    For example, integrating kimamula/ts-transformer-keys:

    const keysTransformer = require('ts-transformer-keys/transformer').default;
    const transformer = (service) => ({
    	before: [ keysTransformer(service.getProgram()) ],
    	after: []
    });
    
    // ...
    plugins: [
    	typescript({ transformers: [transformer] })
    ]
    

Declarations

This plugin respects declaration: true in your tsconfig.json file. When set, it will emit *.d.ts files for your bundle. The resulting file(s) can then be used with the types property in your package.json file as described here.
By default, the declaration files will be located in the same directory as the generated Rollup bundle. If you want to override this behavior and instead use declarationDir, set useTsconfigDeclarationDir: true in the plugin options.

The above also applies to declarationMap: true and *.d.ts.map files for your bundle.

This plugin also respects emitDeclarationOnly: true and will only emit declarations (and declaration maps, if enabled) if set in your tsconfig.json. If you use emitDeclarationOnly, you will need another plugin to compile any TypeScript sources, such as @rollup/plugin-babel, rollup-plugin-esbuild, rollup-plugin-swc, etc. When composing Rollup plugins this way, rollup-plugin-typescript2 will perform type-checking and declaration generation, while another plugin performs the TypeScript to JavaScript compilation.
Some scenarios where this can be particularly useful: you want to use Babel plugins on TypeScript source, or you want declarations and type-checking for your Vite builds (NOTE: this space has not been fully explored yet).

Watch mode

The way TypeScript handles type-only imports and ambient types effectively hides them from Rollup's watch mode, because import statements are not generated and changing them doesn't trigger a rebuild.

Otherwise the plugin should work in watch mode. Make sure to run a normal build after watch session to catch any type errors.

Requirements

  • TypeScript 2.4+
  • Rollup 1.26.3+
  • Node 6.4.0+ (basic ES6 support)

Reporting bugs and Contributing

See CONTRIBUTING.md

Description
Rollup plugin for typescript with compiler errors.
Readme MIT 21 MiB
Languages
TypeScript 96.9%
JavaScript 3.1%