Currently, theeslint-plugin-tslint throws if any of:

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

orlintFile are missing. IflintFile 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:

constshouldProvideParserServices=shouldGenerateServices&&extra.projects&&extra.projects.length>0;

This is despite there being agetASTAndDefaultProject, 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 thetsconfig.json can be relative, but it's by default calculated relative toprocess.cwd() and not to the currenteslintrc 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 thetslint.json also be relative to either the currenttsconfig.json, the currenteslintrc, or to also do a ancestor lookup from the current file.

I think that for most people's use cases theprocess.cwd() orpath.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 everythingexcept these use cases. Note thatpath.resolve(__dirname, "tslint.json") would still be wrong if a specific project has a differenttslint.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 differenttsconfig.json nested inside an outertsconfig.json that belongs to the same project. e.g. a service worker would haveworker instead ofdom in itslib 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.