Set `tsconfig.json` defaults
Closed this issue · 11 comments
I'd add declaration: true, target: es5 and noImplicitAny: true.
Related to #5.
Just curious, why declaration: true if everything is a .d.ts file already?
@louy Haven't done enough tests on it, but at least locally there are slightly different rules around having to re-export types. E.g. when the TypeScript compiler sees us using a type that we've imported but didn't re-export it's an error when we're emitting declarations because the type can not be named. I'd have to re-create the use-case I run into this though.
If you mean function XX uses private type YY then it's only when you write a regular .ts file
Could be that. Feel free not to add it for now, if you want. I'll try to replicate it. Figured it couldn't hurt to add anyway, since that's the context it'll be used in.
So for example:
// index.ts
interface Test {}
export const test: Test = {};can't be converted to a .d.ts file because you cannot put anything in a declaration file without exporting/declaring it. so this is an invalid declaration file:
// index.d.ts
interface Test {} // <-- error. you should either export or declare this interface.
export const test: Test;That's why you get a warning sometimes with declaration: true.
I don't like it because it might make writing tests harder if we start using one tsconfig file instead of two. Plus it means more cleanup.
@louy Was that last comment for something else?
Oh no. it was about this:
Figured it couldn't hurt to add anyway, since that's the context it'll be used in.
Why would that mean we use one tsconfig.json file? It'd be the same set of changes, wouldn't it? Anyway, I'll replicate an example first.
I didn't mean that. I was just saying in case something changes in the future. But I guess you're right. There's no reason for us to make such change anyway.
Ok, guess I didn't understand your statement 😄 I'll close this now, since we've merged the first two options I defined. I'll reopen if I discover an issue.