When certain TS errors are encountered while compiling a module, the /dist/types/*.d.ts file may omit interfaces, or be missing entirely. Neither npm run-script problems or npm test ends up catching this, making it very easy to release broken library versions.
To reproduce:
- Create a new library from the libkit blueprint
- Put this at the top of
/src/index.ts
type WithHello<T> = T & { hello: 'world' };
export interface Foo {
name: string;
}
export interface Bar extends WithHello<Foo> {}
export const x: Bar = {
hello: 'world',
name: 'libkit'
};
- Run
npm run-script problems & npm run-script build (note it exits successfully)
- Check the contents of
/dist/types. It will be empty
- Change
/src/index.ts
- type WithHello<T> = T & { hello: 'world' };
+ export type WithHello<T> = T & { hello: 'world' };
- Run
npm run-script problems & npm run-script build (note it exits successfully)
- Check the contents of
/dist/types. It will contain the appropriate interfaces/types
This particular TS error is more likely to slip through -- it won't cause tests to fail. I suggest we either make npm run-script problems detect this kind of thing, or hard fail in the presence of any error that could result in incomplete output.
When certain TS errors are encountered while compiling a module, the
/dist/types/*.d.tsfile may omit interfaces, or be missing entirely. Neithernpm run-script problemsornpm testends up catching this, making it very easy to release broken library versions.To reproduce:
/src/index.tsnpm run-script problems & npm run-script build(note it exits successfully)/dist/types. It will be empty/src/index.tsnpm run-script problems & npm run-script build(note it exits successfully)/dist/types. It will contain the appropriate interfaces/typesThis particular TS error is more likely to slip through -- it won't cause tests to fail. I suggest we either make
npm run-script problemsdetect this kind of thing, or hard fail in the presence of any error that could result in incomplete output.