Skip to content
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

Add DefinitelyTyped runner #19815

Merged
merged 9 commits into from
Nov 8, 2017
Merged

Add DefinitelyTyped runner #19815

merged 9 commits into from
Nov 8, 2017

Conversation

sandersn
Copy link
Member

@sandersn sandersn commented Nov 7, 2017

Adds a test runner that compiles DefinitelyTyped packages with the currently built compiler. You must have a DefinitelyTyped repo named DefinitelyTyped next to your Typescript repo.

The test only outputs a log file to baselines/local/definitely/ when there is a failure. Currently about 75 packages have compile failures. I expect this number to fluctuate up and down rapidly based on DefinitelyTyped's amount of traffic, so I have not included the baselines here, after discussion with @mhegazy. A run takes about 15 minutes on my machine, so it's simple, if slow, to baseline from master when needed.

I just tested on #17765 and the experience is many times better and faster than the shell scripts I used before.

Assumes that ../DefinitelyTyped holds the DefinitelyTyped repo.
1. Only `npm install` packages with a package.json
2. Add `workingDirectory` to runnerBase to differentiate input directory
from output directory (which should be different for definitelyRunner).
3. Don't output anything on success.
@sandersn sandersn requested review from weswigham and mhegazy November 7, 2017 18:19
@sandersn
Copy link
Member Author

sandersn commented Nov 7, 2017

By the way, for @andy-ms, 31 of the 78 errors that DefinitelyTyped has when compiling on master were from missing lib entries from dependencies. The others are a random mish-mash of errors that have been introduced since 2.0.

Copy link
Member

@weswigham weswigham left a comment

Choose a reason for hiding this comment

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

Also, maybe dt instead of definitely mostly because I think t=dt is shorter and I'm liable to misspell t=definitely a few times.

const timeout = 600000; // 600s = 10 minutes
if (fs.existsSync(path.join(cwd, 'package.json'))) {
const stdio = isWorker ? "pipe" : "inherit";
const install = cp.spawnSync(`npm`, ["i"], { cwd, timeout, shell: true, stdio });
Copy link
Member

Choose a reason for hiding this comment

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

Should we delete a package-lock.json before running npm i? As is, if a DT package updates a dep, I don't think it'd get tested here.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ugggg. Is there a way not to emit package-lock.json? I'd rather do that instead.

Copy link
Member Author

Choose a reason for hiding this comment

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

Nope! Guess I'll have to remove it!

@weswigham
Copy link
Member

If we're not committing the baselines, I suppose we have no interest in adding it to the daily cron build? Would this be something we'd be more comfortable with as like a weekly build? Or is it because the DT repo already has similar associated tests?

@sandersn
Copy link
Member Author

sandersn commented Nov 7, 2017

  1. Yes, at this point we don't want to baseline for a couple of reasons. (1) DefinitelyTyped isn't clean and will likely fluctuate a lot until (if) it's clean; (2) this is currently intended as an automatic way to check new changes with DT faster (3) also that dt-runner claims DT is clean, even if the compiler itself disagrees.
  2. I'll switch to dt. I don't like acronyms, but definitely is hard to type.

@mhegazy
Copy link
Contributor

mhegazy commented Nov 7, 2017

If we're not committing the baselines, I suppose we have no interest in adding it to the daily cron build? Would this be something we'd be more comfortable with as like a weekly build? Or is it because the DT repo already has similar associated tests?

we already have another test run going against DT. this one is more of a local validation after a change.

public workingDirectory = DefinitelyTypedRunner.testDir;

public enumerateTestFiles() {
return Harness.IO.getDirectories(DefinitelyTypedRunner.testDir);
Copy link
Contributor

Choose a reason for hiding this comment

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

do you want to add an assert here or something to let users know that DefinitllyTyped was not found in the expected place instead of silently not running any tests.

public workingDirectory = DefinitelyTypedRunner.testDir;

public enumerateTestFiles() {
return Harness.IO.getDirectories(DefinitelyTypedRunner.testDir);
Copy link
Member

Choose a reason for hiding this comment

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

It might be worth throwing an error if DefinitelyTypedRunner.testDir is empty/does not exist (rather than the usual behavior of getDirectories, which I believe just produces undefined or an empty list). After all, without that, an empty or missing folder is a passing DT suite, which could be misleading if you run this with DefinitelyTyped cloned in the wrong location.

Copy link
Member Author

Choose a reason for hiding this comment

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

Turns out getDirectories throws already, which I think is good enough.

Copy link

Choose a reason for hiding this comment

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

Why does a function called enumerateTestFiles return a list of directories?

@mhegazy mhegazy requested a review from a user November 7, 2017 19:18
@mhegazy
Copy link
Contributor

mhegazy commented Nov 7, 2017

@andy-ms can you take a look as well.

// Read in and evaluate the test list
const testList = this.tests && this.tests.length ? this.tests : this.enumerateTestFiles();

describe(`${this.kind()} code samples`, () => {
Copy link

Choose a reason for hiding this comment

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

This looks like code copied from elsewhere -- can you just inherit?

}
Harness.Baseline.runBaseline(`${this.kind()}/${directoryName}.log`, () => {
const result = cp.spawnSync(`node`, [path.join(__dirname, "tsc.js")], { cwd, timeout, shell: true });
// tslint:disable:no-null-keyword
Copy link

Choose a reason for hiding this comment

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

Nit: use // tslint:disable-next-line, and indent it with the other statements.
Also, can this code be shared with code elsewhere?

@@ -93,6 +93,7 @@
"loggedIO.ts",
"rwcRunner.ts",
"userRunner.ts",
"definitelyRunner.ts",
Copy link

Choose a reason for hiding this comment

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

The file you added is named dtRunner instead, which implies this isn't being used?

Copy link
Member Author

Choose a reason for hiding this comment

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

Just by gulp. Fixed.

@sandersn
Copy link
Member Author

sandersn commented Nov 8, 2017

OK, I pulled everything up into a superclass except a couple of properties. I stuck all three classes in one file since the subclasses are now, essentially, just pieces of configuration (that still needs to be newed).

}
}

class DefinitelyTypedRunner extends ExternalCompileRunnerBase {
Copy link

Choose a reason for hiding this comment

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

This is starting to look like it should be just another instance of a class instead of its own class.

Copy link
Member Author

Choose a reason for hiding this comment

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

True, except that Wesley is shortly going to want to put in more code into the UserCodeRunner, and I already need to put more code into the DefinitelyTypedRunner to skip ExpectErrors. I'll keep it the way it is for now and we can simplify later if neither of those efforts work out.

Harness.Baseline.runBaseline(`${this.kind()}/${directoryName}.log`, () => {
const result = cp.spawnSync(`node`, [path.join(__dirname, "tsc.js")], { cwd, timeout, shell: true });
// tslint:disable-next-line:no-null-keyword
return result.status === 0 ? null : `Exit Code: ${result.status}
Copy link
Member

@weswigham weswigham Nov 8, 2017

Choose a reason for hiding this comment

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

As mentioned in person, check result.status and result.stdout and result.stderr instead of just result.status - we want to capture any output even when we report success.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yep, done.

I've got git problems and I'm not even on Windows!
@sandersn sandersn merged commit 594ac01 into master Nov 8, 2017
@sandersn sandersn deleted the add-definitely-typed-runner branch November 8, 2017 23:45
@@ -105,7 +105,7 @@ var harnessCoreSources = [
"projectsRunner.ts",
"loggedIO.ts",
"rwcRunner.ts",
"userRunner.ts",
"externalCompileRunner.ts",
Copy link
Contributor

Choose a reason for hiding this comment

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

Jakefile, but not gulp?

The official TS homepage refers to gulp. Does it mean both gulp/jake need to be used, depending on area of the project?

Copy link

Choose a reason for hiding this comment

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

If they don't behave the same it's a bug.

Copy link
Member Author

Choose a reason for hiding this comment

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

Gulp uses the tsconfig edited below.

@microsoft microsoft locked and limited conversation to collaborators Jun 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants