Repository navigation
Wrapping logic seems to be weirdly different between ESM vs CJS versions #138
Description
Example:
const cliuiCJS = require('cliui')
import('cliui').then(({ default: cliuiESM }) => {
const uiCJS = cliuiCJS({})
const uiESM = cliuiESM({})
const text = `usage: git tag [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] [-e]
<tagname> [<commit> | <object>]
or: git tag -d <tagname>...
or: git tag [-n[<num>]] -l [--contains <commit>] [--no-contains <commit>]
[--points-at <object>] [--column[=<options>] | --no-column]
[--create-reflog] [--sort=<key>] [--format=<format>]
[--merged <commit>] [--no-merged <commit>] [<pattern>...]
or: git tag -v [--format=<format>] <tagname>...`
console.error('~ ~ ~ ~ ~ ~ ~ ~ ~ ~')
console.error('cjs')
uiCJS.div({
padding: [0, 0, 0, 0],
text,
})
console.log(uiCJS.toString())
console.error('~ ~ ~ ~ ~ ~ ~ ~ ~ ~')
console.error('esm')
uiESM.div({
padding: [0, 0, 0, 0],
text,
})
console.log(uiESM.toString())
})
/* output:
~ ~ ~ ~ ~ ~ ~ ~ ~ ~
cjs
usage: git tag [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] [-e]
<tagname> [<commit> | <object>]
or: git tag -d <tagname>...
or: git tag [-n[<num>]] -l [--contains <commit>] [--no-contains <commit>]
[--points-at <object>] [--column[=<options>] | --no-column]
[--create-reflog] [--sort=<key>] [--format=<format>]
[--merged <commit>] [--no-merged <commit>] [<pattern>...]
or: git tag -v [--format=<format>] <tagname>...
~ ~ ~ ~ ~ ~ ~ ~ ~ ~
esm
usage: git tag [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] [-e]
<tagname> [<commit> | <object>]
or: git tag -d <tagname>...
or: git
tag [-n[<num>]] -l [--contains <commit>] [--no-contains <commit>]
[--points-at <object>] [--column[=<options>] | --no-column]
[--
create-reflog] [--sort=<key>] [--format=<format>]
[--merged <comm
it>] [--no-merged <commit>] [<pattern>...]
or: git tag -v [--format=<format>]
<tagname>...
*/I'm not sure why, but the esm results seem to wrap at very confusing places, differently from the cjs version.
Activity
isaacs commentedon Apr 29, 2023
Ah, it looks like the cjs version is setting up the Mixin with different values:
Whereas the mjs does this:
So the difference appears to be that the functions in
string-utils.tsare not equivalent.isaacs commentedon Apr 29, 2023
Confirmed, this fixes the issue:
I'm guessing the reason for not using
wrap-ansiin this way is to support Deno and browsers, which do not havecreateRequire. But the wrap method instring-utilsis not working properly, so there's a bug there.It'd probably be best to ditch wrap-ansi entirely (including in the cjs version) and fix the
wrapmethod instring-utils.ts, yes?isaacs commentedon Apr 29, 2023
Ugh, and it'd be trivial to update strip-ansi, wrap-ansi, and string-width to ESM, but that would drop support for cjs, because those modules are ESM-only.
Can do it with a npm alias, idk if that's too weird, but it would at least fix the issue.
fix: handle strings the same in cjs, esm, and deno
shadowspawn commentedon Apr 29, 2023
See also: #89
Related: yargs/yargs#2112 (comment)
isaacs commentedon Apr 30, 2023
Fixed by #139
fix: handle strings the same in cjs, esm, and deno
add examples, temporarily use git fork of cliui
Netail commentedon Mar 6, 2024
Any update on this? @shadowspawn (PR #143 ) Experiencing the following issue with jest;
shadowspawn commentedon Mar 6, 2024
No update
Interested in knowing more about your context to understand what the error message might be about, and whether the proposed PR will help. This issue is about cliui not wrapping when used from esm which is due to complications around
string-widthand cjs/esm but does not (normally) cause runtime import errors. Just lack of wrapping.Is your project pulling in
cliui(e.g. v8.0.1) or@isaacs/cliui(v8.0.2)? If your project is pulling in@isaacs/cliui, are you using Yarn v1? Do you have a public repo where I can try and reproduce?Netail commentedon Mar 6, 2024
So our project uses jest for unit testing, where a lower level dependency uses string-width.
I can create a small test environment
Netail commentedon Mar 6, 2024
I've created a test environment; https://github.com/Netail/jest-string-width
yarn install->yarn testshadowspawn commentedon Mar 6, 2024
Great, thanks @Netail , I'll give that a try in next couple of days.
(I can see in the
yarn.lockbothcliuiand@isaacs/cliui, so first question answered already.)shadowspawn commentedon Mar 7, 2024
Reproduced with Yarn 1. The Jest problem is triggered by the use of aliases in #139 which is published in
@isaacs/cliui. Yarn is getting confused with the aliased (string-width-cjs) and unaliased (string-width) packages.Details
I was able to get a working install by deleting the
node_modulesfile and creating an emptyyarn.lockfile before installing with yarn 1.22.21, but I suspect it is fragile and not a reliable fix.This output is from the example repo and an install with the original
yarn.lock.The only installed package that uses alias
string-width-cjsis@isaacs/cliu. Yarn thinks multiple packages are usingstring-width-cjs, but of course they don't and in their code they requirestring-widthand break when they get a newer esm-only version.The suspect entry in the
yarn.lockfile is:isaacs commentedon Mar 8, 2024
@arcanis This is another example of the "yarn 1 deduplicating aliased packages incorrectly" issue.
@Netail I have not checked, but I'm willing to be that this would not be a problem with any other package manager. Try using npm, pnpm, or latest yarn (v4). Yarn 1 should not be used, as long as this bug prevents it from correctly resolving dependency graphs.
Netail commentedon Mar 9, 2024
When installing yarn (
npm i -g yarn) it uses v1 by default. (Meaning a lot of people still use v1 and will potentially run into the same issue) Wouldn't it make more sense to update the string-width package, so it would work with v1?arcanis commentedon Mar 9, 2024
I tried to release a 1.22.22 release which should fix this issue. Running the reproduction in eslint/eslint#17215 (reply in thread) with
yarn@1.22.22instead ofyarn@1seems to work. Can you try to upgrade and let me know?shadowspawn commentedon Mar 9, 2024
I retested reproduction from @Netail . Looks good with
yarn@1.22.22.I needed to delete the
yarn.lock(which I expected) and then install worked as expected. Checkingyarn why string-widthlooks tidy.For reference, the yarn fix is: yarnpkg/yarn#9023
shadowspawn commentedon Mar 9, 2024
(I'll try a couple of different reproductions from #139 as well.)
Netail commentedon Mar 9, 2024
Yes seems like my issue has been resolved with v1.22.22, that's great! Thank you guys very much :)
shadowspawn commentedon Mar 9, 2024
I reproduced problems with packages used in #139 (comment) with
yarn@1.22.21, and fixed withyarn@1.22.22. (rimraf and web-ext and yargs.)callmeteus commentedon Apr 18, 2024
Just for a feedback, I've had this problem and upgrading to yarn 1.22.22 as cited worked perfectly.
add examples, temporarily use git fork of cliui
bcoe commentedon Mar 16, 2025
@shadowspawn you have more context as to whether #165 fully addresses some of these open issues around wrapping.
I'm going to ship that PR to unblock yargs, but not close these issues yet.
shadowspawn commentedon Mar 23, 2025
cliui 9.x has support for wrapping in esm (and is esm-only)
Beep boop, let's fix it