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
rollup-plugin-typescript2
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: falseimportHelpers: truenoResolve: falsenoEmit: false (Rollup controls emit)noEmitOnError: false (Rollup controls emit. See #254 and theabortOnErrorplugin option below)inlineSourceMap: false (see #71)outDir:./placeholderin cache root (see #83 and Microsoft/TypeScript#24715)declarationDir: Rollup'soutput.fileoroutput.dir(unlessuseTsconfigDeclarationDiris true in the plugin options)moduleResolution:node(classicis deprecated. It also breaks this plugin, see #12 and #14)allowNonTsExtensions: true to let other plugins on the chain generate typescript; update plugin'sincludefilter to pick them up (see #111)
Some compiler options have more than one compatible value
module: defaults toES2015. Other valid values areES2020andESNext(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'sincludeoption to add"*.js+(|x)", "**/*.js+(|x)"(might also want toexclude"**/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:stringThe current working directory. Defaults to
process.cwd(). -
tsconfigDefaults:{}The object passed as
tsconfigDefaultswill be merged with the loadedtsconfig.json. The final config passed to TypeScript will be the result of values intsconfigDefaultsreplaced by values in the loadedtsconfig.json, replaced by values intsconfigOverride, and then replaced by forcedcompilerOptionsoverrides 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.jsonfile (tsconfigs can themselves be chained withextends, 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
verbosityto3and look forparsed tsconfigif you get something unexpected. -
tsconfig:undefinedPath to
tsconfig.json. Set this if yourtsconfighas 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: trueSet to false to avoid doing any diagnostic checks on the code. Setting to false is sometimes referred to as
transpileOnlyby other TypeScript integrations. -
verbosity: 1- 0 -- Error
- 1 -- Warning
- 2 -- Info
- 3 -- Debug
-
clean: falseSet to true for clean build (wipes out cache on every build).
-
cacheRoot:node_modules/.cache/rollup-plugin-typescript2Path 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: trueBail 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: falseDeprecated. OS native paths are now always used since
0.30.0(see #251), so this no longer has any effect -- as if it is alwaystrue. -
objectHashIgnoreUnknownHack: falseThe plugin uses your Rollup config as part of its cache key.
object-hashis used to generate a hash, but it can have trouble with some uncommon types of elements. Setting this option to true will makeobject-hashignore 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 withclean: trueonce in a while and definitely before a release. (See #105 and #203) -
useTsconfigDeclarationDir: falseIf true, declaration files will be emitted in the
declarationDirgiven in thetsconfig. 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: peerDependencyIf 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:undefinedexperimental, TypeScript 2.4.1+
Transformers will likely be available in
tsconfigeventually, 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