parser.createProgram is not being exported

[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

1. mkdir typescript-eslint-bug-no-createprogram
2. yarn init -y
3. yarn add eslint @typescript-eslint/parser
4. Check node_modules/@typescript-eslint/parser exports contents.

Attached screenshots at the bottom.

Expected Result

Should be exported.

Actual Result

I tried to use inside eslintrc.js and it threw saying that parser.createProgram is not defined.

Additional Info

I tried to import from @typescript-eslint/typescript-estree as well and got the same result.

Versions

package	version
@typescript-eslint/parser	4.26.1
TypeScript	4.3.2
ESLint	7.28.0
node	14.17.0

Notice on this file above how it's missing a third import but still has a trailing comma, for some reason createProgram is getting stripped from there.

export { parse, parseForESLint, ParserOptions } from './parser';
export { ParserServices, clearCaches, } from '@typescript-eslint/typescript-estree';
export declare const version: string;
//# sourceMappingURL=index.d.ts.map

"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.version = exports.clearCaches = exports.parseForESLint = exports.parse = void 0;
var parser_1 = require("./parser");
Object.defineProperty(exports, "parse", { enumerable: true, get: function () { return parser_1.parse; } });
Object.defineProperty(exports, "parseForESLint", { enumerable: true, get: function () { return parser_1.parseForESLint; } });
var typescript_estree_1 = require("@typescript-eslint/typescript-estree");
Object.defineProperty(exports, "clearCaches", { enumerable: true, get: function () { return typescript_estree_1.clearCaches; } });
// note - cannot migrate this to an import statement because it will make TSC copy the package.json to the dist folder
// eslint-disable-next-line @typescript-eslint/no-unsafe-assignment
exports.version = require('../package.json').version;
//# sourceMappingURL=index.js.map

[bradzacher]

It's not getting stripped. It hasn't been released yet.
We release to the npm latest tag on mondays.

If you want to play with this new api - use our canary tag on npm

[bradzacher]

@rdsedmundo please comment back once you've tested and let us know how it goes!
We'd love to hear what sort of performance improvements you get.

Worth noting that @JamesHenry is working to make this the default for CLI runs in #3512.
Also as an FYI @uniqueiniquity - look a real-world user already getting onto it!

[rdsedmundo]

I wasn't focused on performance improvements (although that will be good in the future!), my use case was writing a custom module resolution (#2771) that enables absolute paths within cross-package imports in a monorepo.

Actually, I ended up using parserOptions.programs just, created my own ts.Program using the Compiler API and it worked wonders. Thank y'all so much for enabling this feature.

I also had to duplicate the logic into a custom tsc CLI for running the type checking with the awareness of the absolute paths + a language service for VSCode. It's unfortunate that TypeScript doesn't support a global hook for this in the tsconfig.json and we have to duplicate this everywhere. microsoft/TypeScript#16607 which asks for this is about to complete 4 years next week.

[bradzacher]

my use case was writing a custom module resolution (#2771) that enables absolute paths within cross-package imports in a monorepo.

oh shit - I didn't even think about that.
this a really awesome possibility that's enabled with this new API.

I know the original usecase Ben was thinking of was for a large project to reuse a project for both linting and typechecking.
So you could probably share your code around and write your own script wrappers for typechecking and linting (and doing both at the same time).

[rdsedmundo]

One difficulty that I'm facing is that the eslint server grows fast in memory usage because it creates a new program almost every time I edit the file in the IDE (because it reads the eslintrc.js again).

I proceeded to cache the program using the tsconfig path, similarly to what you already do with the 'watch programs', it worked, but the problem now is that my program source files are outdated as I don't have access to the dirty file from the IDE before it's saved on the disk, so I can only see the lint problems upon saving the file.

I'd need to do something similar as this, but the useProvidedPrograms don't get access to the code variable, and even if it did I'm not sure how @typescript-eslint could pass that downstream 🤔 , perhaps it could have an overload like this:

module.exports = {
  parserOptions: {
    programs: [
       (code, filePathIn) => {
         const program = getCachedProgram();
         // here I mimic the same logic from the createWatchProgram.ts#L278
       },
    ]
  }
}

A similar problem arises for a new file being created in the disk which won't be inside the ts.createProgram, so if I receive those two parameters I can check if it's not inside and put it in.

Ultimately, I'll end up having to implement a lot of things that you've already done (and better, with tests and edge cases) in the createWatchProgram file, so maybe after all the suggestion you had made here of having a parserOptions.resolveModuleNames is the best way to go with this.

Do you have any thoughts? Thanks.

[rdsedmundo]

I gave up reinventing the wheel and added support for a parserOptions.moduleResolver option.

#3516