Skip to content

feat!: yargs is now ESM first #503

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 13 commits into
base: main
Choose a base branch
from

Conversation

shadowspawn
Copy link
Member

@shadowspawn shadowspawn commented Apr 13, 2025

Stop shipping dual esm/cjs. Ship just esm and rely on require(esm) support in recent versions of node to support CJS users.

The main testing code "moved" from .cjs to .mjs with minor changes, but the diff is messy because both files existed.

Following yargs moving from dual CJS/ESM to ESM-only: yargs/yargs#2451

@shadowspawn
Copy link
Member Author

shadowspawn commented Apr 13, 2025

The linting is out of date, and I abandoned my first try at copying setup form yargs when I realised yargs is not currently linting .ts files! 😅 [Edit: I was confused about state of yargs, gts uses eslint and so .ts files are linted.]

eslint has had a lot of work over last year. standardx is unsupported, but there is now an active fork: neostandard. I haven't used gts anywhere else so not sure how current that is.

@bcoe are you still keen on standard and/or gts, or should I just work on getting base eslint setup for now?

@Lightning00Blade
Copy link

For the Puppeteer issue - https://pptr.dev/troubleshooting#issues-with-apparmor-on-ubuntu
You can check the example change for GitHub Actions - https://github.com/puppeteer/puppeteer/blob/main/.github/workflows/ci.yml#L145

@bcoe
Copy link
Member

bcoe commented May 1, 2025

@bcoe are you still keen on standard and/or gts, or should I just work on getting base eslint setup for now?

gts is what my old team at Google wrote and uses, so I got in the habit of using it out of the box. I don't have a strong preference, if setting up the baseline eslint is easier for you.

Let's just pick a good out of the box configuration and use it.

Co-authored-by: Nikolay Vitkov <[email protected]>
@shadowspawn
Copy link
Member Author

Thanks for comments Benjamin. I'll have another go at updating gts and dropping standardx. I got a bit lost in the weeds in first attempt.

@shadowspawn
Copy link
Member Author

shadowspawn commented May 2, 2025

Progress update.

Second experiment with linting. I switched from standardx to gts for npm run check. Temporarily suppressed linting on yargs-parser-types.ts as it was throwing a couple of errors blocking linting other files.

Lots of errors, but mostly prettier related. Perhaps not surprising switching from one opinionated linter to another. 😅

(I will not apply lots of formatting changes as part of this PR.)

$ npm run check
...
✖ 1668 problems (1668 errors, 0 warnings)
  1661 errors and 0 warnings potentially fixable with the `--fix` option.

Suppressing the prettier checks, 106 errors of only two sorts. e.g.

    32:56  error  "./string-utils.js" is not published         n/no-unpublished-import
   113:77  error  Unexpected function expression               prefer-arrow-callback

@shadowspawn
Copy link
Member Author

Some yak-shaving working through CI tests. Still sorting:

  • eslint yargs-parser-types.ts
  • browser on ubuntu
  • optimize on ubuntu
  • (prettier)

@bcoe
Copy link
Member

bcoe commented May 6, 2025

@shadowspawn feel free to send me an email when yak shaving is done 👍

@shadowspawn
Copy link
Member Author

Short version: dropping the broken+stale "Optimize" test using tscc.

Long version

Dropping the "Optimize" CI test which was originally added in #373.

  1. It doesn't currently work.
  2. The test was quite specific, using Closure Compiler as an example optimising compiler which showed up a problem (with that compiler) at the time.
  3. The tscc project has not been updated in 3 years.
  4. the way the tscc compiler works may not make sense with an esm project. The output starts:
$ npx @tscc/tscc
TSCC: tsickle converts TypeScript modules to Closure modules via CommonJS internally."module" flag is overridden to "commonjs".

@shadowspawn
Copy link
Member Author

Ready for review

Note: prettier is currently disabled (ignoring *) to minimise churn in this PR. Will do a separate PR just to run Prettier.

@shadowspawn shadowspawn marked this pull request as ready for review May 14, 2025 06:48
@@ -1,27 +0,0 @@
import cleanup from 'rollup-plugin-cleanup'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Glad to see this go away.

@@ -10,7 +10,7 @@ jobs:
runs-on: ubuntu-latest
strategy:
matrix:
node: [12, 14, 16]
node: [20, 22, 23]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

24 is out right, perhaps drop 23 in favour of 24?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good suggestion, done

Copy link
Member

@bcoe bcoe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit around using Node 24 in testing matrix.

@shadowspawn
Copy link
Member Author

I have added the default export trick for CommonJS, which required bumping module in tsconfig.json to es2022. I looked at some of what was added in es2022 and available in LTS versions of Node.js.

(We didn't hit this issue and need to do bump module in Yargs because it has an explicit entry file not generated from TypeScript.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants