kazushisan

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)

Thanks! will work on a fix. my original assumption was that users would `npm i` beforehand.

possibly... not a priority at this moment but contributions are welcome!

You need a valid tsconfig that defines the scope of the project and it seems renovate’s tsconfig doesn’t meet this requirement. You can always --skip manually as an alternative option.

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?

My understanding is that Knip is for detecting unused things and that it's auto-fix feature is still experimental, but with that out of the way...

- In general, I personally do not like the idea of having to add another config file in my repo. I feel it's contradictory that I need to add more to my codebase to clean up the clutter in my codebase. I understand that relying on tsconfig to specify the target files has its pros and cons but I hope that my tool will encourage users to maintain their tsconfig. - Knip has its own ecosystem around removing unused stuff in your codebase (not limited to exports). I personally prefer tools that are more single-purposed and does one thing right so I don't have any ideas for expanding features; It will be focused on auto-fixing unused code caused by unncessary `export`s.

Perhaps you need to specify skip option for the entry point file?

I was initially using it but decided to write my own tool because I was too lazy to go through the result of ts-prune and delete the code myself :P

Thanks for the input! I think there may be a misunderstanding about what this does. Existing linters work great for detecting unused code within a file but once you add `export` to it, you can’t detect unused code with linters even if it’s not referenced from any file.

You’re right that this tool may not be useful for some codebases. If your modules are more like “scripts” that include side effects, deleting modules just because it’s not referenced may break things. That should not be the case for react projects that are based on components.

In our development process, we don’t allow the changes made by this tool to be deployed automatically. Instead we make sure the changes are okay by creating a pull request and reviewing. We treat it more like an assistant that does all the cumbersome clean up work in no time.