mct validate lints on files not included in eslint config

[laurhinch]

eslint.config.mjs

import ts from "@typescript-eslint/eslint-plugin";
import tsParser from "@typescript-eslint/parser";
import minecraftLinting from "eslint-plugin-minecraft-linting";

export default [
	{
		files: ["scripts/**/*.ts"],
		languageOptions: {
			parser: tsParser,
			ecmaVersion: "latest",
		},
		plugins: {
			ts,
			"minecraft-linting": minecraftLinting,
		},
		rules: {
			"minecraft-linting/avoid-unnecessary-command": "error",
		},
	},
];

out/.csv (snippet)

ESLINT,1,Info,,"JS file: /node_modules/@minecraft/creator-tools/info/PathLengthFileGenerator.js",,,
ESLINT,1,Info,,"JS file: /node_modules/@minecraft/creator-tools/info/ProjectInfoItem.js",,,
ESLINT,100,Error,,"'reject' is defined but never used.",,,
ESLINT,1,Info,,"JS file: /node_modules/@minecraft/creator-tools/info/ProjectInfoSet.js",,,
ESLINT,100,Error,,"'info' is defined but never used.",,,
ESLINT,100,Error,,"'infoSet' is defined but never used.",,,
ESLINT,100,Error,,"'contentIndex' is defined but never used.",,,
ESLINT,100,Error,,"Empty block statement.",,,
ESLINT,100,Error,,"'formatString' is defined but never used.",,,

Heavily minimizes the potential use-cases for this tool as I'd ideally want to run it in a CI environment where node_modules/ exists.

[mammerla]

Yeah, it basically uses it's own (internal) config file. Certainly it should not lint on node_modules (and @minecraft/creator-tools shouldn't have errors either, but there are 100 things in node_modules that will blow it up). That brings up a bigger question, though: while I modify the config to fix the node modules issue, really, the config should be externalized. But then, if the config is externalized, should I even include eslint in MCT or would you be just as happy doing eslint val separately?

[laurhinch]

Very good point, I think the most appealing use-case for the validator is to run it in a CI environment as an alternative to gathering content logs in-game. I don't know if the validator is a reasonable equivalent to loading the packs in-game, but that's what I'd personally use it for. Since linting is not unique functionality to this tool, I think it would be fine for ESLint to be run separately.

Maybe a way to disable running eslint with the mct val command? Ideally the tool would include testing suites that are functionally equivalent to the marketplace validation, without any extra rules for style or best practices. Would also be nice if the process returned an error code to use in pipelines, unless it does already.