I noticed a few projects failing when Dependabot updated tsd from 0.14 to 0.15. Using git bisect I traced this to f5b69ed20d8393655dca501088f229b519afc0ad, specifically:
Presumably if any of these typings used DOM types, that would fail similarly. Digging further, it seemed suspicious that the test for adding DOM by default explicitly enables dom as an override:
If dom is enabled by default, the test fixture should not have to override. Turns out this was needed because otherwise findConfigFile traverses upwards until it finds a tsconfig.json file, so tests were inheriting the options used to build tsd itself by default.
In order to get test coverage more akin to end usage, I renamed the tsconfig file to exclude it from automatic discovery.
The resulting object from getOptionsFromTsConfig has lib mapped lib.${lib}.d.ts form. So without a tsconfig.json, the DOM test fails. If lib is transformed into full filenames, it passes.
When working directly with a CompilerOptions, I can't find any public method that would transform the array of lib keys to their filenames. It should be safe to go with a mapping function since the only lib entries that don't obey that strict relationship is mutable targets like esnext, which don't seem like they would be specified in tsd.
I could also convert the compiler options back to their tsconfig.json representation and use convertCompilerOptionsFromJson instead.
Not invested in any particular fix here, just wanted to provide a thorough report. Happy to revise.
I noticed a few projects failing when Dependabot updated tsd from 0.14 to 0.15. Using
git bisectI traced this to f5b69ed20d8393655dca501088f229b519afc0ad, specifically:https://github.com/SamVerschueren/tsd/commit/f5b69ed20d8393655dca501088f229b519afc0ad#diff-e717ee248865fa4044ef4561e4692693459eb15f9c1605b12ca42b8f38226fa3R37
Changing
lib.es2017.d.tstoes2017results in errors when typings use core ES types likeRegExp,Array, andJSON(Cannot find name ${type}).https://github.com/bendrucker/creditcards/pull/43 https://github.com/bendrucker/creditcards-types/pull/70 https://github.com/bendrucker/snakecase-keys/pull/49
Presumably if any of these typings used DOM types, that would fail similarly. Digging further, it seemed suspicious that the test for adding DOM by default explicitly enables
domas an override:https://github.com/SamVerschueren/tsd/commit/f5b69ed20d8393655dca501088f229b519afc0ad#diff-ec66651dab3235538c4084a1f2f27a2a10d2752f03b28af09fbd18a16b4384baR5
If
domis enabled by default, the test fixture should not have to override. Turns out this was needed because otherwisefindConfigFiletraverses upwards until it finds atsconfig.jsonfile, so tests were inheriting the options used to buildtsditself by default. In order to get test coverage more akin to end usage, I renamed the tsconfig file to exclude it from automatic discovery.The resulting object from
getOptionsFromTsConfighaslibmappedlib.${lib}.d.tsform. So without a tsconfig.json, the DOM test fails. Iflibis transformed into full filenames, it passes.Those library mappings come from here:
https://github.com/microsoft/TypeScript/blob/fe4a6709da77c7eb7cff1ba2a31963e18037bc86/src/compiler/commandLineParser.ts#L20
When working directly with a
CompilerOptions, I can't find any public method that would transform the array of lib keys to their filenames. It should be safe to go with a mapping function since the onlylibentries that don't obey that strict relationship is mutable targets likeesnext, which don't seem like they would be specified in tsd.I could also convert the compiler options back to their
tsconfig.jsonrepresentation and useconvertCompilerOptionsFromJsoninstead.Not invested in any particular fix here, just wanted to provide a thorough report. Happy to revise.
Closes #101