At the express suggestion of a package maintainer whose package has over 36 million weekly downloads, I submit the following (original submission/comment is chalk/chalk#373 (comment)):

I wrote:

@babel/preset-typescript gets about 3.7 million weekly downloads; typescript gets about 7.9 million.

This is not a rigorous analysis... but, because the problem arises with const enum being unsupported by @babel/preset-typescript (because it only works with code that conforms to isolatedModules), that means about half of the typescript projects out there can't use chalk 3.x.

@babel/preset-typescript also doesn't fully support TS namespaces. The TS maintainers have publicly said that ES6 modules are the future; on the other hand, they've also publicly said they have zero plans to remove namespaces from the language. I don't know for certain, but I expect they would not be open to removing const enum either.

There is a plugin (babel-plugin-const-enum) that can help with the const enum situation. However, it's not a wonderful solution because those of us who use tsc to typecheck — which is everyone since babel/preset-typescript doesn't do any typechecking — need to disable the isolatedModules option. But it's important to have that option in place in projects using @babel/preset-typescript, especially in larger projects, to ensure that contributors don't commit code that won't work with it.

In summary: many TypeScript projects won't be able to use chalk 3.x if it retains const enum. It's not really any one's fault, it's just how things are given the technical constraints of @babel/preset-typescript and the practical need to typecheck with tsc in a manner that detects code that isn't compatible.

I'm sure none of the above will convince you to change your mind, and there's certainly no resentment on my part. I wasn't sure how many people who encounter this issue understand the core of the problem, so I hope my comment is helpful. Thanks for all your hard work on this wonderful library!

The maintainer replied:

They don't need to remove it, just officially discourage it ... const enum is a real pain-point for users. You can fix Chalk here, but there will be lots of other projects using const enum and are you going to spend time on this every time you encounter a project using const enum?

Is there something I'm missing as a consumer of this library running into problems with isolatedModules clashing with const enum?

Is there something the package maintainer could do to alleviate the problem in a manner that doesn't sacrifice the performance gains of const enum?

Is there something the TypeScript maintainers can do to help improve the situation?

cf. #30590 and facebook/create-react-app#4837 (comment).

Much thanks for your time and consideration!