Hello @Bartheleway, thanks for your feedback. Did you tried to use the ignores option to handle this? This is mainly an issue with the style of such doc string comments. So if you use the option ignore with the build in ignores: ['js-comments'] this should ideally solve your issue.

@schorfES, I wasn't aware of this option. I tried it today and result is pretty good.

I see at least one issue of using it. It seems to ignore all checks between comment boundaries which is not what I am trying to achieve.

For example (with explicit indent / EOL):

/**<lf>
<space><space>some bad stuff * could be bad line ending<cr><lf>
<tab><space><space>whatever
*/<lf>

This would pass regardless of line ending and indentation settings. In my use case I only want to accept the extra whitespace in front of the * on multiline comments.

/**<lf>
<space>* Some comments<lf>
<space>*/<lf>

I see that my PR is only handling js comment style so it needs to be improved. The good thing is it only add acceptance for that extra front space before the * without disabling other checks.

I know that it is only my use case (following VS Code / js doc / java doc / ... convention) and that other projects might want to fully ignore what is between comment boundaries so I think both system should coexist. Happy to discuss it further and to improve my PR accordingly 😄

I was confused around the trailingspacesToIgnores option, naming can probably be improved. Now I understand that this allow to choose activation in ignores. Maybe we can create eolToIgnores et indentationToIgnores on the same model.

I’m a bit confused as well, but as far as I remember, EOL is always validated when the option is turned on, regardless of any ignores affecting the line (see README). Indentation, however, is disabled by ignores specifically for cases where comments have “incorrect” indentation. So, I believe the new options might not be necessary. I’ll need to double-check this...

@Bartheleway I checked all the options. Here’s a list showing which ones respect ignores 👍 and which do not 👎:

• 👍 maximum newlines option (see here)
• 👍 trailingspaces option with trailingspacesToIgnores (see here)
• 👍 indentation options (see here)
• 👍 guess indentation option (see here)
• 👎 newline at end of file option (see here)
• 👎 end of line option (see here)

As you can see, most of the options respect ignores, except for these two options. The end of line option does not consider ignored lines and always validates line endings, as it’s generally undesirable to mix line endings, whether in code or comments. I think this aligns with what you expect. So from my current perspective, I don’t see a need for the two new settings, eolToIgnores and indentationToIgnores. Hope I didn’t misunderstand you.

Yes I agree, I don't really understand how I got no report about EOL inside comment as reading the code, it should raise it ...

The only remaining "issue" is that indentation option respect too much the ignore option to my taste 😄 I would expect to still validate the indentation on comment lines in front of * instead of just not validating the line.

Maybe this is just my edge case and I am the only one concerned about comments like:

class MyClass {
    /**
Weird stuff
 */
    function myMethodWithBadComment () {
        // Some code
    }

    /**
     * Weird stuff
     */
    function myMethodWithGoodComment () {
        // Some code
    }
}

Hi @Bartheleway, thank you for double-checking. If you still encounter a case where EOL is not working as expected, please consider opening a PR with a test case so we can address it.

Regarding indentation for ignored lines, this primarily relates to the scope of this project. To fulfill your request, Lintspaces would need to become a syntax parser utilizing an AST, similar to ESLint and similar tools. However, Lintspaces is designed to be language-agnostic, focusing on rules that apply to any text (or source code) file rather than specific language syntax.

While the multiline comment style with a vertical line of * characters (/** ... */) originates from Javadoc in Java and has been adopted by languages like JavaScript for documentation tools, your request involves more than simple text line checking—it introduces a dependency on specific language syntax. Although this project is written in JavaScript and is likely used primarily in JavaScript or web-based projects, Lintspaces aims to remain flexible and usable with any kind of text file.

For this reason, I believe adding built-in support for this type of comment exceeds the scope of the project. However, we can explore solutions that maintain the project’s language-agnostic nature. One idea is to introduce hooks to Lintspaces, which would allow users to extend the linting process with custom code for extra validations or modifications to the report. In this case, a hook could be used to add a regular expression to check whether the * is correctly indented for ignored lines.

What do you think of this approach?

Interesting approach. Going this way would probably means that we will see in a near future some "node-lintspaces-js", "node-lintspaces-java", ...

• each package will almost have no code except the customisation of the indentation behavior for comments
• every new node-lintspaces version would involve new versions of these packages
• linting a multiple language repo will involve several packages of node-lintspaces-*
  In case no child package appears, this will means people will copy/paste the piece of code that goes into the hook on several projects. I feel having a pre-built option rather than code hook option is more neat.

Another approach would be to get all these language specific constraints in the current package. It will certainly alter a bit the agnostic current nature of the package which for me is fine as long as we don't break it (only linting specific language). As you said, vertical aligned comments comes from java and are now used in other languages. This can be seen as this type of comment is now language agnostic it is just a style of comment which can be then supported by a language agnostic linter 😉 in the same matter the package already implement language specific ignore pattern and this doesn't break the agnostic nature of the package.

Technically speaking, I don't know yet how to implement it correctly but I will definitely explore this path.

I would not expect separate packages for different languages, as the style of these comments is the same across languages. Technically, "node-lintspaces-js" and "node-lintspaces-java" would have nearly identical code. Instead, I can think of shipping these hooks or plugins directly with lintspaces and importing them as needed. For example:

import Validator from 'lintspaces';
import DocStringHook from 'lintspaces/plugins/docstring';

const validator = new Validator({
  hooks: [DocStringHook],
});
validator.validate('/path/to/file.ext');
validator.validate('/path/to/other/file.ext');

const results = validator.getInvalidFiles();

I assume, this approach would address your point as well:

This can be seen as this type of comment is now language agnostic it is just a style of comment which can be then supported by a language agnostic linter 😉 in the same matter the package already implement language specific ignore pattern and this doesn't break the agnostic nature of the package.