📢 Impacting changes in next v7 version: we need you :)

[nvuillam]

We need you to finalize V7 !

Next version v7 of MegaLinter will contain potentially impacting changes

So far with our current tests, most linters seems to behave well, but before releasing it would be best if there are more beta-testers from the MegaLinter community :)

You can test with beta version (replace v6 , v6.x.x.x or latest by beta in your workflows / scripts )

Major updates

Use of relative file paths to call linters

Now the linters are called with the relative file names, on contrary to the absolute file names used from the beginning of MegaLinter

Basically, for example we used to call eslint /tmp/lint/myfolder/myfile.js and now we call eslint myfolder/myfile.js

The only impacting issue seems to be with PRE_COMMANDS that install additonal npm dependencies.

• pre-commands are executed in /node-deps ONLY if they contain npm i or yarn add AND if the cwd is "root" (which is by default). Before it used to be in /node-deps undepending the cwd value
• If they do not work with cwd: root , it will probably work with cwd: workspace
• If you see such impact on your repo , please notify here in a comment :)

Improve secrets security

@josecelano , @cgbosse and @hosom were perfectly right in their article: using MegaLinter means trusting the authors of the 100+ linters with your secrets.

With v7, you just need to trust MegaLinter authors, not all the linters authors, thanks to its new capability to hide environment variables when calling the linters !

See advanced documentation -> environment variables security

Default masked variables list is the following: Do you see others that should be added ?
- GITHUB_TOKEN
- PAT
- SYSTEM_ACCESSTOKEN
- GIT_AUTHORIZATION_BEARER
- CI_JOB_TOKEN
- GITLAB_ACCESS_TOKEN_MEGALINTER
- GITLAB_CUSTOM_CERTIFICATE
- WEBHOOK_REPORTER_BEARER_TOKEN
- NPM_TOKEN
- DOCKER_USERNAME
- DOCKER_PASSWORD
- CODECOV_TOKEN
- GCR_USERNAME
- GCR_PASSWORD
- SMTP_PASSWORD

New linters

• cljstyle
• kubescape
• Vale

Other updates

You can see the many other changes list in the CHANGELOG

Many thanks to everyone for your help to make MegaLinter better everyday :)

Note: you can also share this post to spread the word :) https://www.linkedin.com/posts/nicolas-vuillamy_megalinter-major-v7-activity-7063547619163156480-aF1n?utm_source=share&utm_medium=member_desktop

[Kurt-von-Laven]

Previously we didn't cd /node-deps for yarn add commands. I don't see what user scenario or project type benefits from that change since MegaLinter doesn't use Yarn. If the user wants to run Yarn commands in a pre-command, I would be inclined to guess that they have a Yarn project and want to run those commands in their workspace, so I don't think we should intervene in that case.

[nvuillam]

Agreed, I'll remove the part about yarn :)
Anyway, with current beta, if cwd is workspace and not root, a yarn add command remains untouched :)

[Kurt-von-Laven]

I tried the latest beta image with the following added to .mega-linter.yaml:

TYPESCRIPT_ES_CLI_EXECUTABLE: [yarn, run, eslint]

I hit:

Unable to get number of errors with regex_sum and ✖ ([0-9]+) problem
Unable to get version for linter [eslint]
/usr/bin/yarn run eslint --version returned output: (1) yarn run v1.22.19
error Couldn't find a package.json file in "/"
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Unable to extract version with regex re.compile('\\d+(\\.\\d+)+') from ERROR
❌ Linted [TYPESCRIPT] files with [eslint]: Found 1 error(s) - (3.59s)
--Error detail:

Oops! Something went wrong! :(

ESLint: 8.39.0

No files matching the pattern "yarn" were found.
Please check for typing mistakes in the pattern.


❌ Error(s) have been found during linting
To disable linters or customize their checks, you can use a .mega-linter.yml file at the root of your repository
More info at https://megalinter.io/beta/configuration/

In debug mode, I noted: [eslint] command: ['yarn', 'run', 'eslint', 'yarn', 'run', '--no-ignore', '--fix', <bunch>, <of>, <files>, ...]. I was surprised to see yarn run listed twice, but that explains why ESLint complained that it couldn't find a file matching "yarn".

[nvuillam]

Hmmm double yarn run is indeed a bug, probably related to the fact that now cli_executable is a list and not a string, I'll reproduce and fix :)

[Kurt-von-Laven]

I have a feeling you already spotted this, but I suspect the double yarn run come from this line.

[nvuillam]

@Kurt-von-Laven nop hadn't spotted it yet, thanks for the tip :)

Fixed in #2609

[nvuillam]

V7 released :)