update dep, switch to ESM, require 12.20

[jimmywarting]

To keep up with latest version of string width that became ESM only package Then this also has to become a ESM only package

this is required to avoid deduplicated code

[rafaelmaeuer]

@iarna please accept PR from @jimmywarting as updating to string-width ^5.0.1 allows to close https://snyk.io/vuln/SNYK-JS-ANSIREGEX-1583908 with peer-dependencies strip-ansi ^7.0.1 -> ansi-regex ^6.0.1. It also allows mocha to move towards ESM.

[iarna]

I'd take dependency updates (and even modernizing the code to, say, use let and the pad family of functions) but I'm not interested in switching this to ESM at this time. (ESM in node is not something I'm interested in engaging with.)

[iarna]

Alternatively, if you want to do the work to make this dual mode (eg both CJS and ESM in the same published artifact), I'm not opposed to that.

[jimmywarting]

It's a tiny bit problematic to do it the other way around where you use require internally and expose a pointless "esm wrapper" approach

• esm modules can import cjs & esm "sync" and async
• cjs can only import esm async

so if you don't start using import width from 'string-width' (which is a esm only module now) then you will forever be stuck with a older version that is still using require()

---

the only other solution is that you switch to using import and then compile down to cjs for dual support. but that requires you to bundle all the dependencies into on single large bundle so you have 0 dependencies so to speak.

[iarna]

eh, my approach would be to write an extreme trivial script to replace the require, imports and exports to their esm forms at publish time, so there'd be two files in the published artifact, but only one in source control.

I'm just talking string substitution here -- not good in the general case, but fine in limited scope.

[iarna]

Although, the string-width module really is a problem for that plan, as we'd need different versions of that module depending. Tempts me to just rewrite the damn thing using a similar strategy to @iarna/word-count. I wouldn't mind getting off the sindre version escalator anyway. Some modules shouldn't be complex enough to merit updates.