Lint for case-sensitive imports

[jtoar]

Since we recently added TS support for Redwood's directory structure, we seem to now be vulnerable to this bug: microsoft/TypeScript#21736. @KrisCoulson already ran into it, and it's super hard to debug (you think it's a webpack / fast refresh problem at first). This feels like something people could easily run into and spend hours trying to fix.

It seems like our best chance to prevent it is to have some kind of linting of our own. Thoughts?

[vprasanth]

Just going to stress that this really can take hours/days! Especially these days when most devs are constantly context switching. Any tooling to help catch insidious behaviour like this will be amazing! Thank you upfront ✌🏾 🙏🏾

[thedavidprice]

I'd like us to prioritize this for v1-rc

[callingmedic911]

@jtoar @thedavidprice Can we use eslint-plugin-import, specifically no-unresolved rule? It has caseSenstive option (on by default) that should cover it. What do you think?

[thedavidprice]

@callingmedic911 sorry for the delayed reply here. That plugin looks like a good option to explore. My only initial concern (without having researched yet) is that the plugin could collide with some of Redwood's import conventions, e.g. "directory named" convention might have some static analysis issues.

I think the best way to find out would be to open a PR and show a screenshot of the behavior so we can determine if it's what we want. If we have to disable a lot of defaults, it might not be the right fit. But either way odds are you'll learn what the right solution could be. So please go for it if you're up for it!

[callingmedic911]

@thedavidprice You are absolutely right! "directory named" and ** imports are failing with this lint rule. In this case, I think we have to resurrect eslint-plugin-redwood with the custom no-unresolved rule. I'd be glad to take this forward and raise a PR soon.

Also, if we decide to go ahead with the custom lint rule, we can merge eslint-config and eslint-plugin-redwood but doesn't really makes sense in the long run because

1. backward compatibility - currently crwa imports directly from eslint-config
2. as soon TS fixes this issue, we'll need to deprecate and remove this rule anyways - possibly again remove the package if we don't have any other lint rules.

[thedavidprice]

In this case, I think we have to resurrect eslint-plugin-redwood with the custom no-unresolved rule. I'd be glad to take this forward and raise a PR soon.

@peterp given the nature of this potential bug, what do you think about this approach? And/or is there another way forward here?