-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Conversation
@typescript-bot user test this |
The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master. |
There was a problem hiding this 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.
I debated between that and |
Ok, I think that's all of them. Need to run tests and accept new baselines. @typescript-bot user test this |
@sandersn BTW, I switched to using |
A few things: Also, |
@@ -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); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 :( |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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" ] |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
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. |
48232f6
to
8824950
Compare
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? |
You can pick the change the bot generates into a PR of your choosing or generate the baselines locally, yeah. |
@weswigham any other feedback? If not I'd like to merge this so we can get the user tests working again. |
There was a problem hiding this 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.
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. |
Fix failing user tests due to peer dependency issues.
Fixes #42445.