I tried it on https://github.com/renovatebot/renovate

It deleted 100s of files, most of which were Jest test files, and potentially all of which were a mistake. I restored them all with `git restore $(git ls-files -d)`.

I then ran `tsc` on the remaining _modified_ files and `Found 3920 errors in 511 files.`

Obviously at that point I had no choice but to discard all changes and unfortunately I would not recommend this for others to even try.

You should switch the default to not delete any files and modify/remove the files only with some flag (--dry-run=false, --rm, --delete, etc). I just deleted all files accidentally in a monorepo :D Luckily I didn't had any uncommitted changes and could recover using git

I tried it and it's pretty cool, I might introduce it in our company project. I did notice one problem/caveat: It doesn't play nice with dynamic imports. Our project has a few files being lazily imported and the tool seems to think that those files are unused, which is not true, they're just imported with the `import('./file')` syntax.

But other than that it's pretty nice, I might look into the code to see if I can help with that small bug.

I've been using ts-prune[1] for years at this point. The project is in maintenance mode but works fine so I've kept using it. I've been looking into Knip[2] which is recommended by the authors of ts-prune though it's been slow mostly because there's little incentive with the current tool working fine.

[1]: https://github.com/nadeesha/ts-prune

[2]: https://github.com/webpro-nl/knip

Deleted 80% of my project. Glad I could revert it but yeah pretty useless at this point

really nice that you're tool focuses on removing. i've been using https://knip.dev/ for detection in monorepos, but it's cumbersome to remove manually.

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.

This is cool, as a place which uses Typescript for a lot of things, including back-end services we handle it differently. Basically we have a rather strict linting process setup which will warn developers of unused code in development environments and outright refuse it for staging deployment and forward. I’m not sure we would “dare” to automatically remove it, because for the most part there is a reason it is there. Maybe it’s something that needs to be deleted, but it’s almost always something which needs to be handled in some way.

Unused imports is perhaps the one area where I would be comfortable removing unused imports. I would never personally allow a third party package into our environment for something like this. I really don’t want to be rude about it, but it’s too “trivial” to rely on an external import for. Not because your code couldn’t be better than ours, it probably will be, but because it’s an unnecessary risk.

For smaller or personal projects I think many people will rely on something like prettier to do the same.

Great tool! It uncovered a surprising amount of unnecessary exports in our codebase. Really streamlines things.

One interesting observation: when using it with our Next.js project, it flags all page TypeScript files as unused. This inadvertently highlights a potential drawback of file-system based routing - it can lead to less explicit code relationships.

Cool. A prettier plugin does this too. Cant remember which, but maybe https://www.npmjs.com/package/prettier-plugin-organize-impor...?

I'm not trying to be offensive here, but I've realized that the design choices of the tool and the explanation in README was a little too difficult and unfriendly for the average TypeScript user.

I've added a more detailed explanation to README so I hope it will change your mind if you've previously had a negative impression :)

https://github.com/line/ts-remove-unused#readme

Neat! I will add this to my toolbelt.

BTW a complimentary tool I've used in the past is depcheck, it is an npm package that removes unused dependencies from your npm package.json file. Smaller package.json files means faster "npm install" and also smaller docker files.

https://www.npmjs.com/package/depcheck

If you are using vs code, it has an extension: find unused exports. It worked so far pretty well in our projects.

https://marketplace.visualstudio.com/items?itemName=iulian-r...

I've always used https://github.com/pzavolinsky/ts-unused-exports

Has more features (like excluding enums) and works very well in large code bases.

Been passively wanting something like this for a while now. We have a good few dynamic imports so I'll have to work around that (as per another comment), but this is a much appreciated tool in the belt!

Ohh my, this is something that I would love in my projects... OK currently I don't have any Typescript project, only Python.

For python there is a lib for this, but it is a bit crappy.

Any tool that helps delete code safely is a win in my book! Even more so if I happen to personally know the author and randomly stumble over their submission on hn

Isn’t this what tree-shaking is for?

That’s a genuine question — I’m only passingly familiar with tree-shaking so I may have a misunderstanding of what it does.

I think the command in the first image in the readme is wrong. Shouldn't it be `npx @line/ts-remove-unused`?

Pretty cool!

Could this also work with .svelte files, which are essentially html-like files with <script lang="ts">?

Another good alternative. Archived but still in use at work. https://github.com/nadeesha/ts-prune

Does not work quite well with monorepos, just tried but overall a good idea

I searched far and wide for this a few years ago for a disastrous React codebase I inherited that had a lot of unused components, never found anything.

This looks great, particularly the `skip` and `mode` options (which I'm guessing several commenters here missed).

I suppose it should work just as well with monorepos or any other directory hierarchy right? It only "knows" files are unused because they're never referenced in any code within the defined `projectRoot, and it only knows exports are unused whenever they're never imported?

Cool project, will definitely try it soon.

This is basically malware