RyanCavanaugh
commented
4 years ago I really like the idea of a workbench.
I think it's sufficient for the markup language to be able to show the setup behavior without prescribing the expected output; the author can describe in prose what they don't like about it. We've found that emitShouldContain/etc style tests are usually too sensitive to "spelling" effects (e.g. Array<T> vs T[]).
For something like a refactoring, showing the refactorings available (perhaps filtered by a search string?) and their post-render output would be sufficient.
Error message numbers only have "best effort" stability and I'd generally avoid trying to hardcode them. This is also subject to oversensitivity; when we add a new "Here's what we think is going on" error message on top of an existing error message, the observed top-level error code changes. Error positions are also subject to some movement; this is why I generally lean toward "Let people demonstrate the behavior" rather than "Let people prescribe the behavior". Showing version-to-version changes in the demonstrated behavior is also likely to be more instructive than pass/fail.
elibarzilay
orta
weswigham
We want to provide better tools for providing reproductions of TypeScript bugs in issues. In an issue we really only have text to work with, so we need some kind of text representation of a TypeScript project.
Classes of issues
Looking through the bugs label, there are a large amounts of cases we can probably address:
There are a few we probably can't:
I'm interested in expanding either of these lists! ^
Possible solution
Two parts:
We use something like
arcanis/sherlockto run any issues with re-pros on a nightly-ish schedule with different builds of TypeScript and store the results using something like this - this runs TypeScript code with markup which is built for reprosA page on the website which helps you generate a single typescript codeblock which is a reproduction of a bug
Possible Markup
We've been working on a TypeScript markup language for the website and this called ts-twoslash which adds commands inside comments. I'd recommend reading the README for that before expanding some of these examples.
Bad JS Emit
```ts // @showEmit // @emitShouldContain: this string // @emitShouldNotContain: this other string console.log("hello world") ```Bad DTS Emit
```ts // @showEmit // @showEmittedFile: index.d.ts // @emitShouldContain: 123 // @emitShouldNotContain: 456 export const myVariable = "123123" ```This code should be this type
```ts // @noImplicitAny: false const a = 123 // ^? = const a: 123 ``` or ```ts // @noImplicitAny: false const a = 123 // ^? != const a: any ```This code is slow
```ts // @slow const a = 123 // ^? ``` This annotation could indicate that it should fail if it takes over 1sThis code crashes
```ts const a = 123 a.l ``` In theory there shouldn't need to be a crashes annotation, all code should not crash. I'm open to debates on why that might need to be different though.This code should error
```ts // @expectErrors: 4311 const a = "hello" a * a ```This code should not error
```ts const a = "hello" a * a ``` The lack of an error annotation should indicate this. If it is expected that there should be some errors, then it can use the `@errors: 3211` which is already set upThis refactor didn't do what I expected
I'm still a bit hazy on this, in fourslash there are a lot of options here - but to try provide a really high-level ```ts const a = "hello" a * a // ^^^^^! refactor ``` This could create a JSON dump of all the refactoring options maybe?Web Page
We have been working towards having the playground support a custom set of tabs in the sidebar, it's not a far reach to imagine that an editor for twoslash could be the playground but with tabs focused on running ts-twoslash and getting useful results.
Here's a rough idea of what that could feel like:
The blockers on that: