Currently, the eslint-plugin-tslint throws if any of:

      /**
       * The user needs to have configured "project" in their parserOptions
       * for @typescript-eslint/parser
       */
      if (!parserServices || !parserServices.program) {
        throw new Error(
          `You must provide a value for the "parserOptions.project" property for @typescript-eslint/parser`
        );
      }

or lintFile are missing. If lintFile is missing it'll just lint nothing instead of throwing, unless there are inline configs.

parserOptions.project is completely undocumented in @typescript-eslint/parser, and at any rate that would need to be autodetectable for this use case to work. Currently, services are just silently not generated if it's missing:

  const shouldProvideParserServices =
    shouldGenerateServices && extra.projects && extra.projects.length > 0;

This is despite there being a getASTAndDefaultProject, which looks like it could do the right thing. It's just unreachable code unless you already gave a project to begin with.

On further reading, it looks like the tsconfig.json can be relative, but it's by default calculated relative to process.cwd() and not to the current eslintrc being processed, or an ancestor lookup relative to the current file. The option to change that (tsconfigRootDir) is also undocumented and still can't do what I want.

Secondly, it should be possible to make the tslint.json also be relative to either the current tsconfig.json, the current eslintrc, or to also do a ancestor lookup from the current file.

I think that for most people's use cases the process.cwd() or path.resolve(__dirname, "tslint.json") approach could work, but in my use case I'm trying to make a single shareable eslint config for a monorepo and simply reuse it with "eslintConfig": { "extends": ["@scope/eslint-config"] }. This works for me for everything except these use cases. Note that path.resolve(__dirname, "tslint.json") would still be wrong if a specific project has a different tslint.json than the one the shared eslint-config has.

Even if I leave it to run per project, I still have some specific folders that have a different tsconfig.json nested inside an outer tsconfig.json that belongs to the same project. e.g. a service worker would have worker instead of dom in its lib config. I can still probably deal with this through refactoring, but it sounds like something that could/should be supported; or at least vscode can support it.