Changed the scope of this rule to not to use asynchronous code in constructors

This may be tricky because the most famous source-map library provided by Mozilla actually exposes asynchronous constructors and it would put every project that uses that library in an uncomfortable situation:



We could add an exception, though.

Also, my personal opinion here: class constructors are factories. I think that whatever is allowed with functional factories (like createCat) should be allowed with class constructors. Allowing a pattern on certain factories and not some other sounds strange to me.

And, I’m not sure I understand the Why here: what issue do asynchronous constructors create that this rule would prevent? And, coming back to the factory concept, what issues would this rule prevent that don’t also exist with asynchronous functional factories? If we want to implement this rule, I think we need to identify and document the adaptability issues that it mitigates.