Will it remove exports that are only imported for the sake of testing? Eg: it is only imported by files ending in .test.ts or with __test__ as a parent directory?
I’ve tried tools like this in the past within projects that have high test coverage but I have never had any luck because of this edge case.
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)
If you are providing a library, it's possible you are exporting a function that is meant to be used by downstream code, and that function is isolated from other parts of the code (so never used by other functions but only tests)
If you are writing "product" code, most likely this is just dead code. But there are also edge cases where a function is used as the entry point for other code outside the current repository etc.
Put it this way -- if you are given a codebase you have never seen before, and you see a function only imported by test on the first day. Would you remove it without hesitation? Probably not.
I feel this is likely something that must require human experience to be done "correctly".
A custom comparative function that returns true or false based on the special requirements of the project might fix that. I don’t think the project supports this based on a quick look at the documentation but I would love to see this added as a feature.
I’ve tried tools like this in the past within projects that have high test coverage but I have never had any luck because of this edge case.