-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Feb 2019 Definitely Typed failures on typescript@next #29898
Comments
@weswigham Mind taking a look? These all seem related to changes you have made or were discussing with Anders. |
Do we know what day these started failing in DT, so I can narrow down the cause? |
No, we don't have a regular DT run right now: https://typescript.visualstudio.com/TypeScript/_build?definitionId=15 is paused because it always times out. :( |
More failures from DefinitelyTyped/DefinitelyTyped#33038: react-instantsearch-core
Not sure what is going on here. ember, et alThere are about 9 ember packages that fail, all with the same set of 10 errors, all of which are similar. Here's an example:
Seems like it's related to the other ember error. |
it was green yesterday (see DefinitelyTyped/DefinitelyTyped#33011) |
FWIW the ember stuff wasn't showing these specific errors until the dev-20190213 3.4 build, although we were running into another issue that #29787 was intended to resolve. |
Found a few more in DefinitelyTyped/DefinitelyTyped#33051 baidu-app
yargs
stellar-base
|
Any hint when this could be fixed? More and more PRs at DefinitelyTyped get closed because CI is red and as a result they are ignored by the integration team. There is no process defined at DefinitelyTyped to deal with such breakage from outside. Would it be possible to pin the DefinitelyTyped CI to use an older/working version of typescript@next? |
Some updates:
|
If dtslint gets the ability to only run tests for a specific typescript version, it should be possible to split the test suite into a travis test matrix. This lets tests for each typescript version run in parallel instead of serially, and the We are running against a time bomb because as more typescript releases are made, the closer |
@sandersn I agree that typescript@next is not the main pain point, it's just one out of several. Removing tests because they fail is usually not what I propose. The main issue with issues introduced by typescript@next is that the time till a fix is longer as the time granted by @typescript-bot for a PR. In the past mentioning andy-ms often helped but I don't think it's a good idea to put all these issues onto one person. Most people don't resubmit a PR which has been closed by bot; and the few people which do this often faced the issue that bot closed the next PR also. Other reasons for CI failures:
I mostly talk about node typings here which have >1600 other definitions depending on it. if one of them as an issue node fails also in CI. |
@Jessidhia @weswigham dtslint now has a flag My tentative plan is to file a bug whenever Definitely Typed is not clean on typescript@next, much like we do with the user test baselines or the RWC tests. One person on the TS team triages that bug. That should reduce the turnaround time to 24-48 hours. If there is still a problem, then typescript@next can be marked as
Maybe we should think about special-casing node, but I'm not convinced that's a good idea either. |
@sandersn sounds good.
I agree that this is most likely not a good idea. What about following approach:
As I never created a bot I have no idea if this is possible to implement.. |
Reading comments should be reasonably simple -- the natural language part is a giant pitfull but I think it would be a rare usage so probably wouldn't need to be robust. @RyanCavanaugh handles that part of typescript-bot, so I'll discuss it with him next week (he is home sick today). |
Together with processes for getting upstream fixes, is it also under consideration to introduce a process for getting the @typescript-bot to pause auto-closing for individual PRs while fixes elsewhere are in progress? |
More issues into DefinitelyTyped/DefinitelyTyped#33325 on multiple |
This issue is almost completely fixed by
Unfortunately, I also merged #29332 today, adds a lot of new, simple errors in tests, which are not at all careful about their usage of global |
I believe we've cleaned up all these now (and then proceeded to introduce new ones with |
Found by trying to change a whole bunch of package's project URLs in DefinitelyTyped/DefinitelyTyped#32977
d3-array
Looks like a possible change in index access types
ember
Same.
petit-dom
Something to do with JSX? Not sure.
The text was updated successfully, but these errors were encountered: