Hacker News new | ask | show | jobs
by kazushisan 635 days ago
I may be opinionated but I believe that the best practice is to configure a separate tsconfig for test files with project references. As long as the test files are not included in the tsconfig passed to ts-remove-unused, it should remove exports that are only used in test files.

https://www.typescriptlang.org/docs/handbook/project-referen...
2 comments
rickcarlino 635 days ago
In the JavaScript API, it would be nice if there was the ability to have custom comparative functions for this sort of use case. A user defined function that gets called right before final output which allows the user to create custom filtering rules and return a boolean to indicate inclusion or exclusion. I could see this being useful not only for the case I just presented, but also other cases such as NextJS projects that export default functions in pages that are never imported elsewhere in the project.
link
kazushisan 635 days ago
I’ve been using it for my next.js project and passing something like `/pages\//` to `skip` was good enough for me… Is there something I’m missing out?
link
3523582908 635 days ago
hey! I was wondering if you'd be willing to explain what project references are and why you would do test config this way?
link
kazushisan 634 days ago
I wont go into detail about what it is (since the docs are good enough) but in short, it's a feature to let you setup multiple TypeScript projects in the same repo.

Some things that project references will solve: - importing test files from your impl files will throw an error - you can specify what types are available. for example you shouldn't be able to use `@types/node` in your frontend code or the `DOM` type in your test code (or vice-versa) - no type checking the whole repository again just because you changed the test.

I think there's quite some control over how strict you can be when you say you're using TypeScript. Project references is another way of making your config more robust, and it may not be necessary depending on your needs (like when some people disable strict:true). I think it's a better choice and relying on a properly configured project shouldn't be a issue for users who are actually going to use this (who are likely maintainers of their project)

link