--fix flag doesn't work with custom Program

[rdsedmundo]

• I have tried restarting my IDE and the issue persists.
• I have updated to the latest version of the packages.
• I have read the FAQ and my problem is not listed.

Repro

import { logger } from '@charityvest/lambda';

const a = {};
// ["test"] is better written in dot notation. (eslint@typescript-eslint/dot-notation)
logger.info(a['test']);

function b() {
  return true;
}

logger.info(b());

const parsedTsConfig = ts.getParsedCommandLineOfConfigFile(
  './tsconfig.json',
  /*compilerOptionsToExtend*/ undefined,
  { ...ts.sys },
);

const compilerHost = ts.createCompilerHost(parsedTsConfig.options, true);
const program = ts.createProgram(parsedTsConfig.fileNames, parsedTsConfig.options, compilerHost);

// the code you're using to do the parse of the aforementioned code
module.exports = {
  parserOptions: {
    programs: [program],
  },
}

Expected Result

import { logger } from '@charityvest/lambda';

const a = {};
logger.info(a.test);

function b() {
  return true;
}

logger.info(b());

Actual Result

import { logger } from '@charityvest/lambda';

const a = {};
logger.info(a.test true;
}

logger.info(b());

Additional Info

I saw that the allowAutomaticSingleRunInference added a workaround for this by checking if a file has been called inside the parserAndGenerateServices more than once, but unfortunately, there's no way for me to access that from the ESLint config file just. This really limits the usage of the custom Programs functionality if someone relies on the --fix flag.

Versions

package	version
@typescript-eslint/typescript-estree	4.29.3
TypeScript	4.3.2
node	4.17.0

[bradzacher]

This is just a limitation of this custom program infra. It was designed for a very specific use-case (some teams in microsoft linting using custom tooling which already had a program instance), and thus was not designed to handle all cases fully.

With the current API - I don't think that it's possible for us to allow you to provide a custom program AND also allow the system to reactively handle the fix usecase AND also handle the IDE watch usecase.

In a nutshell - we would have to completely redesign the API to take a function which generates programs so that we can regenerate programs on-the-fly when we think we might need to.

[rdsedmundo]

Got it. I originally faced this issue while trying to work around #3798, do you have any insights there? If by any chance you could ping someone from the TS team that you might have a closer contact it'd be great. I was thinking of duplicating in the TS repo to have better chances of getting an answer from them as well because the issue is pretty much TS-related.

[JoshuaKGoldberg]

Same as #3798 (comment), sadly.

[rdsedmundo]

I originally reported this as I wanted a workaround for #3798 so by having a custom program I could run the suite faster, now that there's a solution there, if we allow an option parserOptions.hasInvalidatedResolutions to be provided and plug it into the compiler host it should be enough—at least for me use case, although it's not a solution to the original issue I reported (-"-fix doesn't work with a custom Program").