[no-unused-modules] Feature Request: Option to ignore exports with usage inside the module

Both the original issues for this rule (#186, #361) mention finding dead code as the main motivation for implementing the rule. It is useful for that today, but I think this aspect can be improved further.

A common pattern I see is something like the following. The example is borrowed from Redux, but I see this in a lot of other contexts as well:

export const ACTION = 'I_AM_CONSTANT';

export default reducer(state, action) {
  if (action.type === ACTION) { ... }
}

In the above case, ACTION is often not imported and used in another file, but is still exported to signal to other developers that it is fine to do so if they need it. ACTION is not a dead variable, but it is a dead export, but what I want is to determine if it is dead code.

What if this rule could be combined with something like the functionality from no-unused-vars to verify that an export is neither used in another module or in the same one? This would find actual dead code.

The current use of the rule is something like “find out where you can remove the export statement, and possibly dead code”, which is a fine use case in itself, so I propose adding this functionality behind an option, which also avoids a breaking change.

Does this seem useful and like something that would fit into eslint-plugin-import in general and no-unused-modules specifically?

[Ephem]

Thanks for explaining! While we do things a bit differently I think this makes sense from the library point of view, supporting every usecase quickly gets a library diluted and unnecessarily complex.

This issue has been open a while with no further interest expressed from others, so I’ll go ahead and close it, thanks again for the discussion and your hard work! 💯

[ljharb]

I think your analysis is correct (there’s rules to remove unused vars, and unused exports, but not dead code entirely). However, if you remove all unused vars and all unused exports and all un-imported files, how would you have any dead code left?

This rule and library is only, and should only be, concerned with imports and exports directly and that the proposed option and use case is outside of that scope

Yes, objectively.

There are no valid use cases for exporting unused things, so no-unused-modules should always be on, which lets no-unused-vars find the dead code

This is a bolder stance for me to take, but yes, that’s also my opinion.