check-line-alignment throwing warnings in GitHub Actions on Windows

[TheJaredWilcurt]

So this is a weird one. I added check-line-alignment and it works locally on Windows.

• settings file

My repo is a cross-platform library, so I run GitHub Actions against it on Linux, OSX, and Windows with Node 14 (and Node 8, but ESLint 7 doesn't support Node 8, so just ignore that).

The weird thing is that only the Windows version is failing. And it isn't failing when ran locally on Windows.

Here is the GHA checks. you can switch between each OS and see that it's only on the Windows branch.

• https://github.com/nwutils/create-desktop-shortcuts/runs/2619667209?check_suite_focus=true

No idea what the cause is, all the code is stored in LF, so unless the GHA Windows VM is cloning in CRLF and I need to change some GHA setting, I don't think it's related to that.

[brettz9]

As mentioned, you might try updating the deprecated babel-eslint to @babel/eslint-parser (you will need to add @babel/core (should be just a devDep. if your parser is) as well as add either a Babel config or add requireConfigFile: false to parserOptions. A bug in the parser could perhaps be presenting issues.

[TheJaredWilcurt]

@brettz9 I think I did what you said, but it's still happening:

• https://github.com/nwutils/create-desktop-shortcuts/pull/40/files

is there something I'm missing

[brettz9]

Hmm, ok. (That was just a guess, as thought it'd be good to do that anyways, and ensure we control our variables.) I think solving this might require someone doing a bunch of logging within a fork of the plug-in and seeing where things go awry on Windows.

[TheJaredWilcurt]

Turns out it was line ending related.

I changed .gitattributes from

* text=LF

to

# 2010
* -crlf

# 2020
* text eol=lf

And that fixed it. But at least I got some parser updates too out of this.

[brettz9]

Should have thought of this earlier...

Here is what should be a valid test case but fails:

{
      code: `\r
        /**\r
         * Function description.\r
         *\r
         * @param {string} lorem Description.\r
         * @param {int}    sit   Description multi words.\r
         */\r
        const fn = ( lorem, sit ) => {}\r
      `,
      options: ['always'],
    },

(An equivalent "never" example with alignment removed works fine with carriage returns, however.)

Then there is this invalid case which fails:

{
      code: `\r
        /**\r
         * Function description.\r
         *\r
         * @param {string} lorem Description.\r
         * @param {int} sit Description multi words.\r
         */\r
        const fn = ( lorem, sit ) => {}\r
      `,
      errors: [
        {
          line: 2,
          message: 'Expected JSDoc block lines to be aligned.',
          type: 'Block',
        },
      ],
      options: [
        'always',
      ],
      output: `\r
        /**\r
         * Function description.\r
         *\r
         * @param {string} lorem Description.\r
         * @param {int}    sit   Description multi words.\r
         */\r
        const fn = ( lorem, sit ) => {}\r
      `,
    },

Here's what does work though:

output: `\r
        /**
         * Function description.
         *
         * @param {string} lorem Description.
         * @param {int}    sit   Description multi words.
         */\r
        const fn = ( lorem, sit ) => {}\r
      `,

I think this should probably be reported to comment-parser which I see does split by optional carriage returns while joining with newlines only. Reopening (feel free to unsubscribe if not interested). Update: Now reported to syavorsky/comment-parser#129