Skip to content

Fix broken user and docker tests #42431

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 6 commits into from
Jan 22, 2021
Merged

Fix broken user and docker tests #42431

merged 6 commits into from
Jan 22, 2021

Conversation

rbuckton
Copy link
Contributor

@rbuckton rbuckton commented Jan 21, 2021

Fix failing user tests due to peer dependency issues.

Fixes #42445.

@typescript-bot typescript-bot added Author: Team For Uncommitted Bug PR for untriaged, rejected, closed or missing bug labels Jan 21, 2021
@rbuckton
Copy link
Contributor Author

@typescript-bot user test this

@typescript-bot
Copy link
Collaborator

typescript-bot commented Jan 21, 2021

Heya @rbuckton, I've started to run the parallelized community code test suite on this PR at 9978171. You can monitor the build here.

@typescript-bot
Copy link
Collaborator

The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master.

Copy link
Member

@sandersn sandersn left a comment

Choose a reason for hiding this comment

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

What about --legacy-peer-deps? That seems to be the intended workaround: https://blog.npmjs.org/post/626173315965468672/npm-v7-series-beta-release-and-semver-major

If this works, though, it's fine to merge it.

@rbuckton
Copy link
Contributor Author

I debated between that and --force. I think either will work for now, but you are probably correct (as long as --legacy-peer-deps isn't removed at some point in the future). I was mostly concerned about npm version differences (i.e., if the tests were for some reason run on an earlier version of npm that doesn't yet support --legacy-peer-deps).

@rbuckton rbuckton changed the title Add --force to npm install script for user tests Fix broken user and docker tests Jan 21, 2021
@rbuckton
Copy link
Contributor Author

Ok, I think that's all of them. Need to run tests and accept new baselines.

@typescript-bot user test this

@typescript-bot
Copy link
Collaborator

typescript-bot commented Jan 21, 2021

Heya @rbuckton, I've started to run the parallelized community code test suite on this PR at 48232f6. You can monitor the build here.

@rbuckton
Copy link
Contributor Author

@sandersn BTW, I switched to using --legacy-peer-deps but made it conditional on whether npm's major version is >= 7.

@rbuckton rbuckton marked this pull request as ready for review January 21, 2021 21:32
@rbuckton
Copy link
Contributor Author

A few things:
There seems to be an error a the end of runTests:
image

Also, office-ui-fabric has (expected) failures since they haven't updated their version of tslib to the latest version. @weswigham, is that something we should do manually in the Dockerfile (since we also are overriding the version of TypeScript), or should we just leave it until they update?

@@ -14099,7 +14099,8 @@ namespace ts {
return some((type as IntersectionType).types, isJSLiteralType);
}
if (type.flags & TypeFlags.Instantiable) {
return isJSLiteralType(getResolvedBaseConstraint(type));
const constraint = getResolvedBaseConstraint(type);
return constraint !== type && isJSLiteralType(constraint);
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 have a compiler test for this crash fix?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm honestly not sure how to trigger it. It was triggered by something using typescript to parse just.config.ts in office-ui-fabric, and I'm not sure how deep the rabbit hole goes. At least its verified by the fact that office-ui-fabric is compiling again.

Copy link
Member

Choose a reason for hiding this comment

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

Off the top of my head, I know pattern template literals are returned as their own constraint by computeBaseConstraint, and are.... Kinda recent? So maybe there's a situation with a template triggering it?

const res = cp.spawnSync(isWorker ? `${command} 2>&1` : command, args, { shell: true, stdio, ...options });
if (res.status !== 0) {
throw new Error(`${command} ${args.join(" ")} for ${directoryName} failed: ${res.stdout && res.stdout.toString()}`);
}
return options.stdio === "pipe" ? res.stdout.toString("utf8") : undefined;
Copy link
Member

Choose a reason for hiding this comment

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

We don't actually use this returned value anywhere, do we?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm using it to test the npm version, since --legacy-peer-deps is new in npm 7, so if you're running tests on an older NodeJS/npm that flag would result in an error.

Copy link
Member

Choose a reason for hiding this comment

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

Ahhh, ok

@@ -1,5 +1,5 @@
# node-pty doesn't build on node 12 right now, so we lock to 8 - the version xterm itself tests against :(
Copy link
Member

Choose a reason for hiding this comment

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

Should probably update this comment, too.

@@ -10,6 +10,7 @@ COPY --from=typescript/typescript /typescript/typescript-*.tgz /typescript.tgz
WORKDIR /vscode/build
RUN yarn add typescript@/typescript.tgz
WORKDIR /vscode/extensions
RUN yarn add rimraf
Copy link
Member

@weswigham weswigham Jan 21, 2021

Choose a reason for hiding this comment

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

Is this working around a bug in vscode's own build? Since we clearly don't use rimraf here in the dockerfile.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes. The vscode build is failing because they have a postinstall.js script that runs rimraf to clean up TypeScript files they don't need, but we're running yarn add for our copy of TypeScript before all the dependencies are installed which triggers the postinstall script.

Copy link
Member

Choose a reason for hiding this comment

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

Does yarn have a --ignore-scripts equivalent we should use instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nope, not according to the docs for yarn add.

RUN yarn
ENTRYPOINT [ "yarn" ]
# Build
CMD [ "build" ]
Copy link
Member

Choose a reason for hiding this comment

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

Hm, so the user test previously just applied a custom tsconfig to the contents of the src directory and built it. That actually includes way more than they typecheck in their own build: https://github.com/prettier/prettier/blob/master/tsconfig.json Do we want to continue checking the whole src folder under our own rules like the user test used to, or should we use their build like this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'd probably use their build, since that's what they're running.

@weswigham
Copy link
Member

is that something we should do manually in the Dockerfile (since we also are overriding the version of TypeScript), or should we just leave it until they update?

If it significantly blocks the baseline's usefulness, yeah, we can; otherwise I'd just accept the baseline with the errors until they patch the version themselves.

@rbuckton
Copy link
Contributor Author

If it significantly blocks the baseline's usefulness, yeah, we can; otherwise I'd just accept the baseline with the errors until they patch the version themselves.

I'm unclear as to how I can accept user/docker test baselines. Can I do that from typescript-bot#137? If so, I don't have permission to merge changes in that repo. Or do I need to run them all locally and accept?

@weswigham
Copy link
Member

You can pick the change the bot generates into a PR of your choosing or generate the baselines locally, yeah.

@rbuckton rbuckton mentioned this pull request Jan 22, 2021
@rbuckton
Copy link
Contributor Author

@weswigham any other feedback? If not I'd like to merge this so we can get the user tests working again.

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.

An isolated test for that crash big would still be nice.

@rbuckton rbuckton merged commit ee3fe47 into master Jan 22, 2021
@rbuckton
Copy link
Contributor Author

I'll look into a repro, though I haven't had much luck so far tracking down what specific effects triggered it for the office-ui-fabric project.

@jakebailey jakebailey deleted the fixUserTests branch November 7, 2022 17:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Author: Team For Uncommitted Bug PR for untriaged, rejected, closed or missing bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Maximum call stack size exceeded in isJSLiteralType
4 participants