Disallow module keyword in new code where namespace could be used?

[Arnavion]

We occasionally get people who ask questions about modules and exports, and after some back-and-forth and sharing of code we realize they're mixing features of namespaces and (external) modules based on what they found from the handbook and other places on the internet.

Do you think it makes sense to report an error when using module where namespace could be used instead, with a new --allowInternalModuleKeyword compiler option for existing codebases? This will help steer new users in the right direction while still having minimal impact on existing codebases.

[mhegazy]

We have shied away from syntactic breaking changes, specially here when the value is mainly cleanliness. We use tslint rule to flag these internally.

We should reconsider though, and follow some depreciation process, similar to the 0.8/0.9 days with warning first with a flag to suppress the warning, and then erroring with a flag to allow the old syntax to finally removing it all together.

[RyanCavanaugh]

Simply too much module code out there with nothing else wrong to make this a plausible migration path. TSLint is the tool of choice as usual for enforcing these sorts of things.

[Arnavion]

tslint is far from what new devs reach for, but I understand. Let's hope this is fixed in the new handbook atleast.

[RyanCavanaugh]

Yep, if you see module in our official docs please log a bug.