Skip to content
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

chore: move to ESM, update all dependencies #113

Merged
merged 24 commits into from
Mar 30, 2023
Merged

Conversation

Trott
Copy link
Member

@Trott Trott commented Mar 7, 2023

chalk requires ESM. Sure, let's do it.

nopt doesn't support Node.js 12.x so this is a breaking change to drop 12.x support. (I guess the ESM stuff might also be a breaking change for people using this as a dependency rather than a CLI. Does anyone do that?)

@Trott
Copy link
Member Author

Trott commented Mar 28, 2023

@nodejs/tsc Anyone willing to review this?

.github/workflows/node.js.yml Outdated Show resolved Hide resolved
bin/cmd.mjs Outdated Show resolved Hide resolved
lib/tap.mjs Outdated Show resolved Hide resolved
lib/utils.mjs Outdated Show resolved Hide resolved
lib/utils.mjs Outdated Show resolved Hide resolved
test/cli-test.mjs Outdated Show resolved Hide resolved
test/utils-test.mjs Outdated Show resolved Hide resolved
test/validator.mjs Outdated Show resolved Hide resolved
test/validator.mjs Outdated Show resolved Hide resolved
lib/validator.mjs Outdated Show resolved Hide resolved
@Trott
Copy link
Member Author

Trott commented Mar 28, 2023

The coverage report in tests is now broken. Maybe tap doesn't support ESM coverage? (I haven't looked. I'm just guessing.) Replacing with c8 should work if all else fails. Can do that in a subsequent PR. Or I can do it in this PR if people are confident it's the right way to go. Coverage has been advisory-only anyway.

Old output:

> tap --no-check-coverage --coverage-report=text-summary


=============================== Coverage summary ===============================
Statements   : 92.79% ( 451/486 )
Branches     : 76.01% ( 187/246 )
Functions    : 94.2% ( 65/69 )
Lines        : 93.93% ( 434/462 )
================================================================================

Output with c8:

-------------------|---------|----------|---------|---------|-------------------
File               | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s 
-------------------|---------|----------|---------|---------|-------------------
All files          |    94.7 |    87.71 |   94.11 |    94.7 |                   
 ...alidate-commit |     100 |      100 |     100 |     100 |                   
  index.mjs        |     100 |      100 |     100 |     100 |                   
 ...ate-commit/bin |   91.92 |    81.81 |     100 |   91.92 |                   
  cmd.mjs          |   91.92 |    81.81 |     100 |   91.92 | 86-87,100-110     
 ...ate-commit/lib |   88.91 |       80 |   91.66 |   88.91 |                   
  ...at-pretty.mjs |    87.2 |    52.38 |     100 |    87.2 | ...33-34,43-44,63 
  format-tap.mjs   |    58.1 |    61.53 |      60 |    58.1 | ...30,34-48,63-74 
  rule.mjs         |     100 |      100 |     100 |     100 |                   
  tap.mjs          |   94.06 |    94.11 |   93.33 |   94.06 | 65-66,70-74       
  utils.mjs        |     100 |    90.47 |     100 |     100 | 47-48             
  validator.mjs    |   98.01 |    90.47 |     100 |   98.01 | 90-91             
 ...mmit/lib/rules |   99.26 |    97.87 |     100 |   99.26 |                   
  ...s-trailer.mjs |     100 |      100 |     100 |     100 |                   
  fixes-url.mjs    |   94.79 |    93.33 |     100 |   94.79 | 91-95             
  ...ter-title.mjs |     100 |       80 |     100 |     100 | 17                
  line-length.mjs  |     100 |      100 |     100 |     100 |                   
  metadata-end.mjs |     100 |      100 |     100 |     100 |                   
  pr-url.mjs       |     100 |      100 |     100 |     100 |                   
  reviewers.mjs    |     100 |      100 |     100 |     100 |                   
  subsystem.mjs    |     100 |      100 |     100 |     100 |                   
  title-format.mjs |     100 |      100 |     100 |     100 |                   
  title-length.mjs |     100 |      100 |     100 |     100 |                   
-------------------|---------|----------|---------|---------|-------------------

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

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

lgtm

Trott and others added 23 commits March 29, 2023 09:45
nopt@7 drops support for Node.js 12.x so we'll drop support too.

BREAKING CHANGE: drop support for Node.js 12.x
Co-authored-by: Michaël Zasso <targos@protonmail.com>
Co-authored-by: Michaël Zasso <targos@protonmail.com>
Co-authored-by: Michaël Zasso <targos@protonmail.com>
Co-authored-by: Michaël Zasso <targos@protonmail.com>
Co-authored-by: Michaël Zasso <targos@protonmail.com>
Co-authored-by: Michaël Zasso <targos@protonmail.com>
Co-authored-by: Michaël Zasso <targos@protonmail.com>
Co-authored-by: Michaël Zasso <targos@protonmail.com>
Co-authored-by: Michaël Zasso <targos@protonmail.com>
Co-authored-by: Michaël Zasso <targos@protonmail.com>
Co-authored-by: Michaël Zasso <targos@protonmail.com>
Co-authored-by: Michaël Zasso <targos@protonmail.com>
Co-authored-by: Michaël Zasso <targos@protonmail.com>
Co-authored-by: Michaël Zasso <targos@protonmail.com>
Co-authored-by: Michaël Zasso <targos@protonmail.com>
Co-authored-by: Michaël Zasso <targos@protonmail.com>
Co-authored-by: Michaël Zasso <targos@protonmail.com>
Co-authored-by: Michaël Zasso <targos@protonmail.com>
@tniessen
Copy link
Member

@Trott is there a reason to use .mjs instead of setting the module type to ESM in package.json?

@Trott
Copy link
Member Author

Trott commented Mar 29, 2023

@Trott is there a reason to use .mjs instead of setting the module type to ESM in package.json?

Personal preference. I prefer .mjs because it is very hard to miss, as opposed to setting things in package.json which seems more magical and hiding things to me.

But also: I know I'm in the minority on this, so I'll update it to set things in package.json.

@aduh95
Copy link
Contributor

aduh95 commented Mar 29, 2023

breaking change for people using this as a dependency rather than a CLI. Does anyone do that?

node-core-utils does that (and that's the package listed in https://www.npmjs.com/package/core-validate-commit?activeTab=dependents FWIW).

Copy link
Contributor

@aduh95 aduh95 left a comment

Choose a reason for hiding this comment

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

Should we drop official support for v14.x at the same time? v14.x EOL is quite close, and that would allow us to switch to node:test for the tests in a future PR.

I'm with you (Rich) for .mjs, but no strong feelings.

@richardlau
Copy link
Member

breaking change for people using this as a dependency rather than a CLI. Does anyone do that?

node-core-utils does that (and that's the package listed in https://www.npmjs.com/package/core-validate-commit?activeTab=dependents FWIW).

I thought it did too, but node-core-utils executes core-validate-commit as a CLI tool: https://github.com/nodejs/node-core-utils/blob/cc4b11c3de20b0c4b28e9973794b51313a7ed766/lib/landing_session.js#L427-L434

@Trott
Copy link
Member Author

Trott commented Mar 29, 2023

Should we drop official support for v14.x at the same time? v14.x EOL is quite close, and that would allow us to switch to node:test for the tests in a future PR.

Can't drop 14.x until nodejs/build#3214 is resolved.

@GeoffreyBooth
Copy link
Member

But also: I know I’m in the minority on this, so I’ll update it to set things in package.json.

I think in this case specifically, it’s better to keep the .js extensions on all the files for more legible git history. Yes it seems like git is able to track all the changes across the renames, but why add that complexity? Simply avoiding an unnecessary rename seems safer.

@Trott
Copy link
Member Author

Trott commented Mar 29, 2023

I think in this case specifically, it’s better to keep the .js extensions on all the files for more legible git history. Yes it seems like git is able to track all the changes across the renames, but why add that complexity? Simply avoiding an unnecessary rename seems safer.

Prioritizing git history over code clarity seems like the wrong trade-off to me, but views on this sort of thing tend to depend on assumptions, speculation, and personal preference. So I've already conceded and named the files back to .js.

const utils = require('../lib/utils')
const subsystem = require('../lib/rules/subsystem')
import { exec } from 'node:child_process'
import fs from 'node:fs'
Copy link
Member

Choose a reason for hiding this comment

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

Nit: All of these could be import fs from 'node:fs/promises'

@@ -3,17 +3,17 @@
"version": "3.20.0",
"description": "Validate the commit message for a particular commit in node core",
"main": "index.js",
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
"main": "index.js",
"exports": "index.js",

Copy link
Contributor

Choose a reason for hiding this comment

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

We probably want to also export the package.json file.

@@ -3,17 +3,17 @@
"version": "3.20.0",
Copy link
Member

Choose a reason for hiding this comment

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

This should probably be a major version bump?

Copy link
Member Author

Choose a reason for hiding this comment

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

We do the version bumps when we release.

Copy link
Member Author

Choose a reason for hiding this comment

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

@Trott Trott merged commit 8cf9e86 into nodejs:main Mar 30, 2023
4 checks passed
@Trott Trott deleted the new-version branch March 30, 2023 15:53
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.

None yet

7 participants