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.
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.
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)
https://www.typescriptlang.org/docs/handbook/project-referen...