8000 Add @typescript-eslint/parser and typescript-eslint to user tests by JoshuaKGoldberg · Pull Request #119 · microsoft/typescript-error-deltas · GitHub
[go: up one dir, main page]

Skip to content

Add @typescript-eslint/parser and typescript-eslint to user tests #119

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jun 13, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Empty file.
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
export const something = () => {};
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
{
"compilerOptions": { "types": ["node"] }
}
24 changes: 24 additions & 0 deletions userTests/typescript-eslint-parser/index.ts
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
import * as parser from "@typescript-eslint/parser";
import * as path from "path";

const code = `
import { something } from '__PLACEHOLDER__';

something();
`;

const fixturesDirectory = path.resolve(__dirname, "fixtures");
const projectDirectory = path.resolve(fixturesDirectory, "project");

parser
.parseAndGenerateServices(code, {
comment: true,
filePath: path.resolve(projectDirectory, "file.ts"),
loc: true,
moduleResolver: path.resolve(fixturesDirectory, "./moduleResolver.js"),
project: "./tsconfig.json",
range: true,
tokens: true,
tsconfigRootDir: projectDirectory,
})
.services.program.getSemanticDiagnostics();
12 changes: 12 additions & 0 deletions userTests/typescript-eslint-parser/package.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@
{
"name": "typescript-eslint-parser-test",
"version": "1.0.0",
"description": "",
"main": "index.js",
"author": "",
"license": "Apache-2.0",
"dependencies": {
"@typescript-eslint/parser": "latest",
"typescript": "latest"
}
}
6 changes: 6 additions & 0 deletions userTests/typescript-eslint-parser/tsconfig.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
{
"compilerOptions": {
"strict": true,
"types": []
}
}
4 changes: 4 additions & 0 deletions userTests/typescript-eslint/test.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
{
"cloneUrl": "https://github.com/typescript-eslint/typescript-eslint.git",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Theoretically, I would think that this is enough to capture everything, right?

(Also, could you to ts-eslint add something that can install the latest TS and check it so you get early warnings too?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Theoretically, I would think that this is enough to capture everything, right?

Our git clone -> yarn install & yarn build isn't what's failing in CI though. It's the yarn test. Does the automation also run tests? (sorry if I missed this, it would explain what you've been trying to convey to me)

(Also, could you to ts-eslint add something that can install the latest TS and check it so you get early warnings too?)

Absolutely: typescript-eslint/typescript-eslint#7093

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The automation only installs without scripts and runs tsc on each tsconfig.json. It never executes code from within the repo, unless you write a script-based test which would do that. If yarn test takes a large amount of time, I don't think we would add it here, but I would me more interested in why things fail only in test and not otherwise... You're still referring to an OOM, right? Not trying to catch errors in the typescript API?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

still referring to an OOM, right?

Exactly. I don't know why it's OOMing yet, but at the very least I'm hoping that running a similar bit of code to the offending tests would catch similar issues.

"types": []
}
0