Add rule to ban direct imports from 'effector/effector.umd', 'effector/effector.cjs', 'effector/effector.mjs'

[NazariiShvets]

Proposal

Add eslint rule to ban direct imports from 'effector/effector.umd', 'effector/effector.cjs', 'effector/effector.mjs' (with autofix)
so it would be possible to catch/fix such cases with linter

Use case

For now i need to do it in PR or manual cleaning once a couple weeks. It would be great to have that automated

[igorkamyshev]

I'm sure why we have to do it 🤔 Can you elaborate a bit? It seems like a bug in JetBrains products, and as I understand, they accept it. I've found a couple of links there, you can subscribe 👇

• https://youtrack.jetbrains.com/issue/WEB-56387/WebStorm-suggests-wrong-imports-because-of-partial-export-field-support-in-package.json
• https://youtrack.jetbrains.com/issue/WEB-62518/Wrong-imports-for-RxJS-7.2.0

[NazariiShvets]

Sure, thanks for suggestion. I did ban it for my local environment, but:

• I also use different IDE`s for specific usecases
• Can't share .idea with my teammates via git because it would trash it with any personal stuff within IDE

I preffer automation over manual checks or dealing with config syncronization accross different IDEs, projects, etc

[igorkamyshev]

Other IDE's do not have this bug, right? So, it is a problem of JetBrains, I sent some links, they confirmed it 😇

Why shall we introduce workarounds for JetBrains' bugs?

[zerobias]

@igorkamyshev I encountered it in vs code more than once, JetBrains just seems to be more prone to this kind of bugs, so I suggest adding this feature