-
-
Notifications
You must be signed in to change notification settings - Fork 153
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
Line break before @returns #782
Comments
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
Apologies about that. The rule doesn't allow enforcing a specific number of lines before a given tag, but if `jsdoc/tag-lines`: ['warn', 'always', {
noEndLines": true
}] However, if you don't want lines between |
I want just one before To me, this looks nicer: /**
* Do something.
*
* @param {string} fooA - Some text
* @param {string} fooB - Some text
* @param {string} fooC - Some text
*
* @returns {string} fooD - Some text
*/ than this: /**
* Do something.
*
* @param {string} fooA - Some text
*
* @param {string} fooB - Some text
*
* @param {string} fooC - Some text
*
* @returns {string} fooD - Some text
*/ or /**
* Do something.
*
* @param {string} fooA - Some text
* @param {string} fooB - Some text
* @param {string} fooC - Some text
* @returns {string} fooC - Some text
*/ |
I stumbled across this issue and have to say: It would be great if I can configure The example of @thernstig is great but + blank lines between same tags of an other group like
I tried something like |
This comment was marked as outdated.
This comment was marked as outdated.
I (and a lot of other people actually) have come to the conclusion that all formatting should be done by formatters (e.g. Prettier, Deno fmt), and not linters that visually report errors in the editor. There are Prettier plugins for formatting JSDoc. If they are not to your taste they can be improved or alternatives can be published. IMO |
@jaydenseric I can agree to that, yet that is a separate issue still. Until it is done, I would at least like this one to be solved. |
@brettz9 this would be awesome if you can fix this, third most upvoted issue now 😄 |
Still no promises of implementing, but I think one key obstacle here is determining how this behavior will work with or be added to the existing I think there must be cases where users may wish to have I also think it makes sense to have a more generic solution allowing line breaks before certain tags (by default, |
@brettz9 I tried to find I agree with your reasoning. Having a generic solution to define which tags to have line breaks before/after would be the best, maybe with a set of defaults for certain tags such as @returns having one before. |
Regarding the missing rules, ah, yes, they are still being truncating per #886 . You can view the rule with the source doc at https://github.com/gajus/eslint-plugin-jsdoc/blob/master/.README/rules/tag-lines.md and the test examples at https://github.com/gajus/eslint-plugin-jsdoc/blob/master/test/rules/assertions/tagLines.js |
@brettz9 I just tried the I checked https://github.com/gajus/eslint-plugin-jsdoc/blob/main/src/defaultTagOrder.js and would probably want the the feature worked nicely with all those tags, adding line breaks between "blocks" of those for how they are sorted with At least I know I definitely would want a line break both before and after |
@brettz9 I thought about this a bit more, and it is possible that there should be a more holistic approach for how to achieve this. But that would require bigger changes probably in the already existing configurations, meaning a breaking change. I bring it up at least to start the discussion. If we check https://developer.wordpress.org/coding-standards/inline-documentation-standards/javascript/#functions it shows: /**
* Summary. (use period)
*
* Description. (use period)
*
* @since x.x.x
* @deprecated x.x.x Use new_function_name() instead.
* @access private
*
* @class
* @augments parent
* @mixes mixin
*
* @alias realName
* @memberof namespace
*
* @see Function/class relied on
* @link URL
* @global
*
* @fires eventName
* @fires className#eventName
* @listens event:eventName
* @listens className~event:eventName
*
* @param {type} var Description.
* @param {type} [var] Description of optional variable.
* @param {type} [var=default] Description of optional variable with default variable.
* @param {Object} objectVar Description.
* @param {type} objectVar.key Description of a key in the objectVar parameter.
*
* @yield {type} Yielded value description.
*
* @return {type} Return value description.
*/ My preference would be to allow me to use something like For example, here is some psuedo-code (not including all parts shown above): "jsdoc/sort-tags": [
"warn",
"always",
{
"tagGroups": [
{
"tags": ["@since", "@deprecated", "@access"],
"linesBefore": 1,
"linesAfter": 1
},
{
"tags": ["@param"],
"linesBefore": 1,
"linesAfter": 1
},
{
"tags": ["@yield"],
"linesBefore": 1,
"linesAfter": 1
},
{
"tags": ["@returns"],
"linesBefore": 1,
"linesAfter": 1
}
],
"mergeLinesAfterAndBefore": 1,
"linesAfterLastGroup": 0
}
], What I want to achieve is to:
I have no idea how maintainable, configurable and similar this approach would be. But it perfectly highlights what I would want to achieve and I guess many others would want. For example https://developer.wordpress.org/coding-standards/inline-documentation-standards/javascript/#functions where the above sample code was stolen from. |
It looks like a fine approach, but I don't expect I'll be able to work on this. |
@brettz9 I understand. You do so much for the echo system already so no one can expect anything more of you, you have given back more than what most do in their life time in open source ❤️ I wish I was the one to implement this but my time is constrained as well right now. |
While I normally appreciate more granular control, do you see a use case where someone would want different spacing for before and after tag groups and not just a merged total between tag groups? |
@brettz9 not really, no. Maybe it is better to leave that out and leave for more granular control later if requested. I would assume users want 1 empty line between tag groups. In the case they want no empty line, the intention is that they should place it in the same tag group. The array order in the tag group should of course matter for sorting within the tag group. edit Then most of the other options can go away as well to start with. The only one I'd wish to keep would be Then I can chose to place them in a specific group at any place, or in its own group e.g. last or first which might be what users want. |
For those who want lines either before the first group or after the last group—since both of these may be of interest to those not using the rule—I think we should add that functionality in another rule. So it should only be lines between groups in this rule. By the way, we already have an "-other" special tag, so I think we can use that instead of "REST". However, rather than sorting the rest alphabetically, it keeps them as is. Since |
… and after) them; fixes gajus#782
If you find some time to kick the tires on #1017 , @thernstig , I did find some energy for this. Again, I think we should have a separate rule to add or remove lines before all tags or after all tags, but I believe it should work for lines between tag groups now. |
… and after) them; fixes gajus#782
… and after) them and removal of whitespace within them; fixes gajus#782
… and after) them and removal of whitespace within them; fixes gajus#782 BREAKING CHANGE: `tagSequence` array of string tags argument must be specified instead as array of `{tags: []}` objects, with each object representing groups which can gain optional whitespace between them; if none are needed, just put all tags into the array of a single `{tags: []}`
… and after) them and removal of whitespace within them; fixes #782 BREAKING CHANGE: `tagSequence` array of string tags argument must be specified instead as array of `{tags: []}` objects, with each object representing groups which can gain optional whitespace between them; if none are needed, just put all tags into the array of a single `{tags: []}`
Amazing work @brettz9, you're a hero 💯 |
Motivation
Line breaks matters for readability, especially having a consistent line break style in documentation. I want to be able to enforce line breaks before
@returns
statements.Current behavior
There is no configuration for it.
Desired behavior
I want this to be invalid:
I want this to be valid (with the new rule)
Or for those who prefer, the other way around (the first example valid, the second invalid).
The text was updated successfully, but these errors were encountered: