-
Notifications
You must be signed in to change notification settings - Fork 17
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
jsdoc: remove deprecated rule jsdoc/newline-after-description #290
Conversation
028b269
to
7aa3fda
Compare
From the plugin release:
Should we add |
Doing so would mean this rule would not be usable in Node.js 14. I don't see the rush. It seems this change coincides with switching from supporting node 14 and 20 for the plugin, so omitting both seems like the only way to support |
Well, I don't think we want JSDoc comments without a line between the description and params. And since Node.js 14 is EOL, I don't see why we couldn't update this rule? |
I'm considering the nature of this package. It's being used in intermediary libraries and CI currently on 14 and on their way up. That eslint itself is still on My reasoning is: Keeping the range open makes it easier for dependents to migrate so (perhaps counter-intuitively) removing support for older runtime versions can slow down deprecations and updates by users and using libraries. |
Is there a way that we can add this conditionally? Detect the version of |
I don't think we need to worry about compatibility with packages that violate the
Agreed with @Mrtenz that it seems better to keep this rule until we can replace it. Unless we decide we don't want it anymore at least. I don't really see the case for dropping this rule so early that we can't yet use its replacement. |
FWIW, trigger for this making change: https://github.com/MetaMask/etherscan-link/actions/runs/4978661619/jobs/8909250375?pr=70 Adding Got some pointers on how to make that CI pass on node.js 20 without this either this change having to remove the dependency alltogether (throwing out baby with bathwater imo) or forcing yarn to ignore As I foresee the same cropping up again in potentially several repos, this could save a lot of future time. |
Just to follow up on the last comment to indicate the subtlety here, in case it was not clear before: Consider for example https://github.com/MetaMask/etherscan-link/blob/c97467095c71e987710d1a61b1b91359d4e4ba16/package.json factors:
current issue:
possible solutions without patching
|
eslint-plugin-jsdoc |
engines.node |
---|---|
39.2.0 | ^14 || ^16 || ^17 |
39.2.4 | ^14 || ^16 || ^17 |
39.2.5 | ^14 || ^16 || ^17 || ^18 |
39.3.0 | ^14 || ^16 || ^17 || ^18 |
39.3.5 | ^14 || ^16 || ^17 || ^18 |
39.3.6 | ^14 || ^16 || ^17 || ^18 |
40.0.0 | ^14 || ^16 || ^17 || ^18 || ^19 |
40.3.0 | ^14 || ^16 || ^17 || ^18 || ^19 |
41.0.0 | ^14 || ^16 || ^17 || ^18 || ^19 |
42.0.0 | ^14 || ^16 || ^17 || ^18 || ^19 |
43.0.0 | ^14 || ^16 || ^17 || ^18 || ^19 |
43.0.1 | ^14 || ^16 || ^17 || ^18 || ^19 |
43.0.2 | ^14 || ^16 || ^17 || ^18 || ^19 |
43.0.3 | ^14 || ^16 || ^17 || ^18 || ^19 |
43.0.4 | ^14 || ^16 - ^20 |
43.0.5 | ^14 || ^16 || ^17 || ^18 || ^19 || ^20 |
43.0.6 | ^14 || ^16 || ^17 || ^18 || ^19 || ^20 |
43.0.7 | ^14 || ^16 || ^17 || ^18 || ^19 || ^20 |
43.0.8 | >=16 |
43.0.9 | >=16 |
Footnotes
-
Compressed summary of plugin version and engines.node field ☝️ ↩
This rule appears to be present in 43.0.7 🤔 https://github.com/gajus/eslint-plugin-jsdoc/blob/v43.0.7/src/rules/tagLines.js |
Somehow I one-off-errored that one in my head every time. Good catch, look like there's a path forward in replacing |
Added Then sorting out the rule switch can be sorted out after. Putting this one in draft until ts 5 compat is solved. Not strictly blocking but makes sense to me to sort that out first. |
7aa3fda
to
9778634
Compare
9778634
to
9952487
Compare
42d0eeb
to
0d3b935
Compare
Do we still want to do this now that #288 has been merged? |
It will have to be disabled for next major (this is the reason '^43' support was dropped from #288). There is no version that supports both |
Will be causing error starting with eslint-plugin-jsdoc@43 gajus/eslint-plugin-jsdoc#1031
0d3b935
to
c059fe7
Compare
Makes sense. As long as we replace it soon, I'm OK with removing it. Migrating between these rules in lockstep would force us into a very narrow range for that peer dependency, which would be a bit awkward to deal with. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Will be causing error starting with eslint-plugin-jsdoc@43
gajus/eslint-plugin-jsdoc#1031