DEV Community: Orta

Type | Treat 2021 - Wrap-up

Orta — Sat, 30 Oct 2021 14:31:39 +0000

Type | Treat Challenge Wrap-up

That's all the challenges done! If you missed any of the challenges they're all available in the Playground here. Let's talk through the final answers to day 5's challenges.

Yesterday's Solution

Beginner/Learner Challenge

In this challenge we were working with an existing object literal which had been as constd. The goal was to use keyof and typeof to extract interesting sets of strings from the object. The first being the keys in the object:

- type SchemeNames = "background" | "textColor" | "highlightOne"
+ type SchemaNames = keyof typeof scheme

Idealy you might have noticed the 'key of' in the comment, which could have led you to keyof, from there you needed to re-use typeof to extract the type from scheme. This gets all of the keys from that constant.

Next, we asked if you could improve

function possibleSchemeItems(colors: any): string[] {
    const keys = Object.keys(colors) as string[]
    return keys
}

In this case, you can switch string to SchemeNames - this example was made so that there was an interesting function to play around with. You could switch colors to typeof schema but nothing you do around Object.keys would keep the types retained. This is kind of interesting, the reasoning is that TypeScript cannot make reasonable guarantees that the return value of Object.keys actually is keyof typeof colors (because of JavaScript prototype chaining) and so you have to re-type that line. Interesting.

function possibleSchemeItems(colors: typeof scheme): SchemaNames[] {
    const keys = Object.keys(colors) as SchemaNames[]
    return keys
}

Next we had you figure out how to get the values of schema as a union:

- type PossibleColors = '#242424' | '#ffa52d' | '#cafe37'
+ type PossibleColors = typeof scheme[SchemaNames]

We tried to be quite explicit in the clue leading up to this one, because jumping to an indexed type might not be instinctive for beginners. This we considered to be the trickiest part of the challenge.

Then to wrap up the challenge, and to make sure the types you are creating are constructive in a real world-ish scenario, we presented a Record to see if you knew that the first parameter can be a list of keys:

- type Scheme = Record<string, string>;
+ type Scheme = Record<SchemaNames, string>;

Which would cause a compiler error with previousScheme - letting you know it worked.

Our answer

Intermediate/Advanced Challenge

For this challenge, we started with the type we wanted you to write, and then tried to find incremental steps which built up in complexity till you hit it.

The total change we were looking for was this:

function handleSale(events: Record<string, (e: Books) => void>) {
  // ... 
}

To:

function handleSale(events: { [Book in Books as `on${Book["genre"]}`]?: (e: Book) => void }) {
  // ... 
}

Getting there is a bit of a jump!

We first asked you to switch the string in the Record to be Books:

- function handleSale(events: Record<string, (e: Books) => void>) {
+ function handleSale(events: Record<keyof IncomingBookMap, (e: Books) => void>) {

The next step was to remove the Record and replace it with its underlaying mapped type:

- function handleSale(events: Record<string, (e: Books) => void>) {
+ function handleSale(events: { [Book in keyof IncomingBookMap]?: (e: Books) => void }) {

The ? being the key that if you searched the TypeScript documentation for "mapping modifier" you'd see the documentation around mapped types which we also improved in the process of making this challenge.

We thought that could be enough for some folk, and that was a good pausing point and thus classed the final change as a bonus. That jump revolved around using key remapping via as in the mapped type.

- function handleSale(events: { [Book in keyof IncomingBookMap]?: (e: Books) => void }) {
+ function handleSale(events: { [Book in Books as `on${Book["genre"]}`]?: (e: Book) => void }) {

The IncomingBookMap existed specifically to add the prefix on to the genre of each book, which is handled by template string literals. All of the documentation for these concepts are in the same page, so after a few reads it should hopefully all make sense.

This system is more or less how the DOM's event system works, and is what the idea is loosely based on, from lib.dom.d.ts:

interface DocumentAndElementEventHandlersEventMap {
    "copy": ClipboardEvent;
    "cut": ClipboardEvent;
    "paste": ClipboardEvent;
}

interface DocumentAndElementEventHandlers {
        addEventListener<K extends keyof DocumentAndElementEventHandlersEventMap>(type: K, listener: (this: DocumentAndElementEventHandlers, ev: DocumentAndElementEventHandlersEventMap[K]) => any, options?: boolean | AddEventListenerOptions): void;
}

Roughly translates to english as "DocumentAndElementEventHandlersEventMap" shows how to handle document.addEventListener("copy", (evt) => { ... }) and what to map the first argument of that function to. The DOM types can't really switch to use a template literal because not all properties have an on prefix, but it's a pretty logical expansion of the idea in specific cases.

Our answer.

Thanks!

There are a few people involved in getting Types | Treat running whose name you don't see on the masthead: Gabriella and Daniel on the TypeScript team, and the folks in the TypeScript Community Discord - especially webstrand and michael. My wife, Danger, should probably also get a shout for helping to provide themes - we've done 40 challenges so far and have to dig pretty deep occasionally to be fun and topical.

Feedback

If you gave Types | Treat a shot, we love for you to run through our 6 question survey which help us figure out how to change and improve. Feedback on Twitter is useful, but there's only so much context you can gve in 280 characters!

From here?

If you've not done the 2020 Type | Treat, it's also good!

If you want to challenge yourself further, check out types-challenges this clever system of type challenges goes all the way up to "very challenging for the TypeScript team" and also run entirely in the TypeScript Playgound. It's great work.

Type | Treat 2021 - Day 5

Orta — Fri, 29 Oct 2021 19:59:59 +0000

Type | Treat Challenge 5

Welcome to the fifth, and last, Type | Treat challenge! These challenges are a series of blog posts which have 2 code challenges in, one for beginners and one for intermediate TypeScript programmers. We're on day five, which means going over the answers from yesterday and have 2 new challenges.

Yesterday's Solution

Beginner/Learner Challenge

This challenge aimed to be generics 101, first introducing the concept of making your function pass a type from the function to the argument:

-  function getBowl(items: any) {
+  function getBowl<T>(items: T) {
      return { items }
  }

The any acted as hint clue about where to look, and this example is almost the first code sample on the Generics chapter in the Handbook, so it felt like a good intro.

The second part involved understanding generic constraints, these are essential tools in helping you define the baselines for types which can be used in your function. In this case we didn't provide the word "constraints" but opted for a more cryptic clue by setting up the function most of the way, then saying you only needed two words:

-  function fillBowl<T>(candy: T) {
+  function fillBowl<T extends string>(candy: T) {
      return { candy }
  }

By saying that T extended string then the string literals are correctly passed through the function - which removes all the compiler errors.

Our answer

Intermediate/Advanced Challenge

The intermediate challenge also invovled generic constraints, so if you had just finished the beginner's then you were in a good place to figure this challenge. The key is to make a

- const check = (data: Competitor[]) => {
+ const check = <Type extends Competitor> (data: Type[]) => {
      return data.map(competitor => {
          if (competitor.weight > 2121.5) throw new Error("Stop the show, world record hit!")
          return { ...competitor, judge: (...args: unknown[]) => { } }
      })
  }

This is testing a few different things:

Writing generics with an arrow function
Using an extends constraint for the interface subtypes
Re-using the type parameter inside the array

We left a tricky problem with this challenge, but explicitly didn't call it out. The function judge: (...args: unknown[]) is a types gap. There is no validating that the judge function actually works like expected. There are two approaches for handling this:

- return { ...competitor, judge: (...args: unknown[]) => { } }
+ return { ...competitor, judge: (...args: Array<T[keyof T]>) => { } }

This version from @faridz974 would ensure that the right values were used in the function (e.g. you couldn't accidentally put in an object to something which could only accept string and numbers) but it ignored the order. An accurate, but whole-heartedly not recommended for production version which does take order into account comes from converting an interface to a tuple on GitHub which is a bit too long to print in here, but here's a working implementation in the playground.

Our answer.

The Challenge

Beginner/Learner Challenge

Update your website's color scheme for Halloween and tidy the codebase up a bit.

Intermediate/Advanced Challenge

Handle a book stores halloween discount event

How To Share Your Solution

Once you feel you have completed the challenge, you will need to select the Share button in the playground. This will automatically copy a playground URL to your clipboard.

Then either:

Go to Twitter, and create a tweet about the challenge, add the link to your code and mention the @TypeScript Twitter account with the hashtag #TypeOrTreat.
Leave us a comment with your feedback on the dev.to post, or in this post.

Best Resources for Additional Help

If you need additional help you can utilize the following:

The New TypeScript Handbook
The TypeScript Community Discord
The comments on each Dev.to post!
Our previous Type | Treat 2020 challenges

Happy Typing :)

Type | Treat 2021 - Day 4

Orta — Thu, 28 Oct 2021 19:20:37 +0000

Type | Treat Challenge 4

Welcome to the fourth Type | Treat challenge! These challenges are a series of blog posts which have 2 code challenges in, one for beginners and one for intermediate TypeScript programmers. We're on day four, which means going over the answers from yesterday and have 2 new challenges.

Yesterday's Solution

Beginner/Learner Challenge

I wonder if we over-indexed on the difficulty here, and we're interested if you dropped off somewhere through this task because we had less submissions than usual for this challenge. The goal was to have you build out a template string literal type which accounted for string input which roughly matched how CSS's stringy variables worked.

You started with:

type Length = string

Which accepts all possible strings, next we show some examples which should always fail. The key one here being that an empty string should fail: "". Next we provided some valid input for you to work with:

type Length = `${number}in`

// Works with:
req("0in")
req("12in")

Giving you a sense that a number can be used in the template slot - which allows for all sorts of possibilities.

Next we gave samples with different prefixes, so "in" and "cm" would need to be handled. To get that right, you would need to use a union:

type Unit = "cm" | "in"
type Length = `${number}${Unit}`

// Works with:
req("0in")
req("12in")
req("1.5cm")
req("20cm")

Next we threw a curve ball - "0" should also be acceptable, this is a bit of a curve ball, but also it's a bit of a trick:

type Unit = "cm" | "in" | ""
type Length = `${number}${Unit}`

// Works with:
req("0in")
req("12in")
req("1.5cm")
req("20cm")
req("0")

The lack of a unit is just an empty string unit! Only one more thing now, and that is allowing a space inbetween the number and unit. This could be done via another type also:

type Unit = "cm" | "in" | ""
type Space = " " | ""
type Length = `${number}${Space}${Unit}`

// Works with:
req("0in")
req("12in")
req("1.5cm")
req("20cm")
req("0")
req("12 cm")
req("14 in")

That was is for the easy parts of the challenge. It's pretty tricky, because it requires that you understand that number can be anything in the template string and to understand how a union can allow for different types of strings inside the type. That's all in the main docs, but it could be a lot of ideas to learn at once.

This challenge also had a set of complications, cases where the version of the the Length type we expected people to build would provide interesting edge cases:

req(`${0.3e21}cm`)
req("-12 cm")
req(`${Infinity}cm`)
req(`${NaN}cm`)

Click to learn about these cases

req(`${0.3e21}cm`)

Acted as a potential clue to an alternative answer for these failing cases:

req(`${Infinity}cm`)
req(`${NaN}cm`)

Because number can be switched out with bigint in the type of Length:

- type Length = `${number}${Space}${Unit}`
+ type Length = `${bigint}${Space}${Unit}`

This meant you couldn't pass in Infinity or NaN but also broke req("1.5cm") because you can't have point values. This could be fixed via:

type Length = `${bigint}${Space}${Unit}` | `${bigint}.${bigint}${Space}${Unit}`

Which describes both possible cases with a "." and without. This technique still doesn't handle the req("-12 cm"), and actually, it introduces a whole new problem: req("-12.-12cm") is allowed!

We spotted a good answer from @danvdk which revolved around using string manipulation instead, by introducing a Digit type:

type Whitespace = '' | ' ';
type Unit = 'in' | 'cm';
type Digit = '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9';
type Length = `${Digit}${number | ''}${Whitespace}${Unit}` | '0';

This solution correctly handles the case of req("-12 cm") but via that number would allow something like req("1-22 cm") - which you can pretend is to handle an input range. It wouldn't be hard to take this solution and reasonably cover additional edge cases. Very cool solution.

Our answer

Intermediate/Advanced Challenge

The intermediate challenge was on type literals mixed with generics functions. The challenge started with this function:

function makeTitle(str: string) {
    return "<spooky>" + str.toUpperCase() + "</spooky>"
}

The goal was to keep track of string literals through this function. To do this, you need to switch the str: string to be a type argument:

function makeTitle<Str>(str: Str) {
    return "<spooky>" + str.toUpperCase() + "</spooky>"
}

You know that the type argument has to be a string, which you can tell TypeScript via <Str extends string>, then you can re-use the Str in the return position:

function makeTitle<Str extends string>(str: Str): `<spooky>${Uppercase<Str>}</spooky>` {
    return "<spooky>" + str.toUpperCase() + "</spooky>"
}

You'd think this would be it, but str.toUpperCase actually converts the str to a string! Tricky, you'd need to think creatively here and you have three options:

Use an as because you know better than the compiler:

function makeTitle<Str extends string>(str: Str): `<spooky>${Uppercase<Str>}</spooky>` {
    const shouty = str.toUpperCase() as Uppercase<Str>
    return `<spooky>${shouty}</spooky>`
}

Override toUpperCase to support template literals:

interface String {
    toUpperCase<T extends string>(this: T) : Uppercase<T>
}

Or create a new function which supports template literals.

This would take the "party" used on line 19 and convert it to "<spooky>PARTY</spooky>". That change would remove the compiler error on addTadaEmoji.

The second part was about re-using the type parameters inside argument for the function. The challenge started with:

function setupFooter(str: string) {
    // validate string etc
    return { 
        name: str.split(",")[0],
        date: str.split(",")[1],
        address: str.split(",")[2]
    }
}

Would lose string literals passed in as str. You knew ahead of time that there were three separate parts of information you were interested in:

function setupFooter<Name extends string, Date extends string, Address extends string>(str: string) {

These could then be used inside the replacement for string:

function setupFooter<Name extends string, Date extends string, Address extends string>(str: `${Name},${Date},${Address}`) {

Which would correctly set up these variables for re-use later:

function setupFooter<Name extends string, Date extends string, Address extends string>(str: `${Name},${Date},${Address}`) {
    // validate string etc
    return { 
        name: str.split(",")[0] as Name,
        date: str.split(",")[1] as Date,
        address: str.split(",")[2] as Address
    }
}

Successfully completing this challenge would show that name, date and address were not string but the strings passed in.

Our answer.

The Challenge

Beginner/Learner Challenge

Make some candy bowls. Then make some very specific bowls.

Intermediate/Advanced Challenge

Run a set of pumpkin competitions

How To Share Your Solution

Once you feel you have completed the challenge, you will need to select the Share button in the playground. This will automatically copy a playground URL to your clipboard.

Then either:

Go to Twitter, and create a tweet about the challenge, add the link to your code and mention the @TypeScript Twitter account with the hashtag #TypeOrTreat.
Leave us a comment with your feedback on here!

Best Resources for Additional Help

If you need additional help you can utilize the following:

The New TypeScript Handbook
The TypeScript Community Discord
The comments on each Dev.to post!
Our previous Type | Treat 2020 challenges

Happy Typing :)

Type | Treat 2021 - Day 3

Orta — Wed, 27 Oct 2021 20:25:16 +0000

Type | Treat Challenge 3

Welcome to the third Type | Treat challenge! These challenges are a series of blog posts which have 2 code challenges in, one for beginners and one for intermediate TypeScript programmers. We're on day three, which means going over the answers from yesterday and have 2 new challenges.

Yesterday's Solution

Beginner/Learner Challenge

There is many ways to decide how to type existing data, you could use literal types when you're sure of the exact formats - or be more liberal and use string when you expect a variety. We opted for literals, but using string is totally cool too.

type UnderripePumpkin = {
    color: "green",
    soundWhenHit: "dull thud"
}
type RipePumpkin = {
    color: "purple" | "orange" | "blue",
    soundWhenHit: "echo-y"
}
type OverripePumpkin = {
    color: "green" | "white",
    soundWhenHit: "squishy"
}

The second part of the challenge used type predicates (or type guards) annotates a function which returns a booleon with narrowing information about the paramters. This means we can tell TypeScript that when the return values to isRipeis true, then the argument pumpkin is of the type RipePumpkin:

- function isRipe(pumpkin: any) {
+ function isRipe(pumpkin: any): pumpkin is RipePumpkin {
       return "soundWhenHit" in pumpkin && pumpkin.soundWhenHit === "echo-y"
  }

Successfully completing this challenge would have no errors, and the type for.

Our answer.

Intermediate/Advanced Challenge

This challenge was first about understanding different read vs write properties available in both classes and interface/typed objects. Personally, I've seen this with document.location a lot where you always get a rich object when you read but can write to that property with a string. We wanted a similar concept, but using punch which for me is generally a 'throw it all in and see what happens' style of drink.

class PunchMixer {
  #punch: Punch = {flavour: '', ingredients: []};

  public get punch(): Punch {
      return this.#punch;
  }

  public set punch(punch: Punch | Punch['ingredients'][number]) {
      if (typeof punch === 'string') {
          this.#punch.ingredients.push(punch);
      } else if ('flavour' in punch) {
          this.#punch = punch;
      } else {
          this.#punch.ingredients.push(punch);
      }
  }
}

This solution uses a mix of private class fields, indexed types and type narrowing to set up a local punch object which is always returned.

The next step was to make this class generic in some form so that a type parameter passed in to the class would dictate what the return value of a vend function was.

- class PunchMixer {
+ class PunchMixer<MixerType> {
+    mixer!: MixerType;

  // ...
+   public vend(): MixerType {
+        return this.mixer;
+    }
  }

We were not too worried about how you passed back the MixerType - our first draft had return {} as MixerType but a private field feels nicer.

Our Answer.

The Challenge

Beginner/Learner Challenge

Figure out how to stop people giving you bad strings for your custom lengths.

Intermediate/Advanced Challenge

Stop losing your literals in Halloween posters

How To Share Your Solution

Once you feel you have completed the challenge, you will need to select the Share button in the playground. This will automatically copy a playground URL to your clipboard.

Then either:

Go to Twitter, and create a tweet about the challenge, add the link to your code and mention the @TypeScript Twitter account with the hashtag #TypeOrTreat.
Leave us a comment with your feedback on the dev.to post, or in this post.

Best Resources for Additional Help

If you need additional help you can utilize the following:

The New TypeScript Handbook
The TypeScript Community Discord
The comments on each Dev.to post!
Our previous Type | Treat 2020 challenges

Happy Typing :)

Type | Treat 2021 - Day 2

Orta — Tue, 26 Oct 2021 19:35:06 +0000

Type | Treat Challenge 2

Welcome to the second Type | Treat challenge! These challenges are a series of blog posts which have 2 code challenges in, one for beginners and one for intermediate TypeScript programmers. We're on day two, which means going over the answers from yesterday and 2 new challenges.

Yesterday's Solution

Beginner/Learner Challenge

The first part of the solution for this challenge used as const to trigger "Literal Inference" - basically telling TypeScript "Don't convert the array to string[] but consider it a constant set of string literals. This meant that playlist[0] stopped returning string and started returning "The Legend of Sleepy Hollow by The Monotones.mp3".

  const playlist = [
      "The Legend of Sleepy Hollow by The Monotones.mp3",
      ...
- ]
+ ] as const

The second part of the challenge used typeof types to extract the type from the playlist array. Without the first change, this would be string but after the change this meant the full array of different types. You then needed to use the type index syntax [number] to declare that you want any potential string from that array.

- function playSong(song: string) {
+ function playSong(song: typeof playlist[number]) {
      api.play(song)
  }

Successfully completing this challenge would raise an error in the final code samples due to a subtle typo.

Our answer.

Intermediate/Advanced Challenge

This pattern is quite common in code we write in TypeScript codebases, you create one function which takes the result of another and keeps passing objects between functions in a pipeline. One of the best techniques for simplifying this design pattern is to use ReturnType with typeof myFunc to map the return type of one function to the paramter of another. This removes the need for intermediary types which need to be updated when the functions change.

  const findOldCostume = () => {
      // ...
      return { jumpSuit, estimate }
  }

- const createNewMask = (costume: any) => {
+ const createNewMask = (costume: ReturnType<typeof findOldCostume>) => {
      // ...
      return { ...costume, mask }
  }

The little extra step at the end was a small reminder that you can use this technique to provide a type which can be re-used everywhere.

type Costume = ReturnType<typeof assembleCostume>

Our Answer.

The Challenge

Beginner/Learner Challenge

Help sort out a large array of pumpkins, and then get cooking soup.

Intermediate/Advanced Challenge

Fresh back from robotics camp, can you make the perfect punch mixer bot?

How To Share Your Solution

Once you feel you have completed the challenge, you will need to select the Share button in the playground. This will automatically copy a playground URL to your clipboard.

Then either:

Go to Twitter, and create a tweet about the challenge, add the link to your code and mention the @TypeScript Twitter account with the hashtag #TypeOrTreat.
Leave us a comment with your feedback on the dev.to post, or in this post.

Best Resources for Additional Help

If you need additional help you can utilize the following:

The New TypeScript Handbook
The TypeScript Community Discord
The comments on each Dev.to post!
Our previous Type | Treat 2020 challenges

Happy Typing :)

Type | Treat 2021 - Day 1

Orta — Tue, 26 Oct 2021 07:09:21 +0000

Type or Treat Challenges

Today we're starting up our second year of Type | Treat (or "Type or Treat".) We will be presenting some "spooky" code challenges that will allow you to dig deeper into the TypeScript language in a fun way.

Starting right now, a new code challenge will be posted every weekday, along with its solution the day after. The last solution will be posted on the weekend.

How To Participate

In order to participate you only need to be able to access the TypeScript website. Though ideally, you share with us your answers via our dev.to blog post mirrors, here, or via Twitter to @TypeScript.

You will want to start here on the blog to find the details on the code challenges for the day. Each post contains 2 links to different challenges which run in the TypeScript playground. Via the playground, you can work on the challenge in your browser and you will be able to test your code live to see if it properly passes the challenge.

How To Share Your Solution

Once you feel you have completed the challenge, you will need to select the Share button in the playground. This will automatically copy a playground URL to your clipboard.

Then either:

Go to Twitter, and create a tweet about the challenge, add the link to your code and mention the @TypeScript Twitter account with the hashtag #TypeOrTreat.
Leave us a comment with your feedback on the dev.to post, or in this post.

Best Resources for Additional Help

If you need additional help you can utilize the following:

The New TypeScript Handbook
The TypeScript Community Discord
The comments on each Dev.to post!
Our previous Type | Treat 2020 challenges

Day 1 Challenges

Beginner/Learner Challenge

Using the new music streaming service from the TypeScript team, Typify, set up and share your halloween playlist with your friends.

Head to this link and help us figure out the best type to use in one of our function parameters!

Intermediate/Advanced Challenge

You've figured out your costume, but making it is a bit of a process. Can you figure out how to make all of the parts come together in a type-safe way?

Head over to start sorting.

Announcing the new TypeScript Website

Orta — Tue, 15 Sep 2020 19:23:02 +0000

Hey folks, I'm happy to announce that the next iteration version of the TypeScript Website has launched on typescriptlang.org.

The new of the website was built out of a desire to make the documentation for TypeScript feel as expansive as its type
system, with a design that fits modern Microsoft styles.

To get a sense of what people wanted, we reached out to the community about where they would like to see improvements and road-mapped based on that feedback.

Community requests generally coalesced into a few major areas:

Navigation can be difficult
The playground feels limited
Missing or not up-to-date docs
It's hard to read up about tsconfig.json

On top of that we wanted:

A revised intro to TypeScript on the homepage
Compiler-backed code samples
Improved accessibility
To support learning TypeScript in your own (human) language

Let's go through these points and learn about how the new TypeScript website addresses them.

Welcome to the new TypeScript Website

We decided on the design and copy for the homepage for TypeScript 6 years ago, but things have changed quite a lot since then. TypeScript has grown up and understands what it wants to be: a type layer above JavaScript that provides great tooling support.

This focus means explaining how the team works with JavaScript standard bodies, describing how DefinitelyTyped allows TypeScript to provide types to un-typed libraries, and teaching how adoption of TypeScript doesn't have to be an all or nothing choice.

Hopefully, the new homepage makes it easier to understand TypeScript's place in the JavaScript ecosystem.

Also, a personal highlight from the re-design, the new TypeScript logo which more closely reflects what people use in the wild:

New Navigation

We addressed a lot of site navigation issues by:

Completely splitting mobile vs desktop site navigation so they are more focused on their domains
Adding search for our documentation
Interweaving code samples for the playground with existing documentation, making it easy to interact with ideas instead of just passively reading

The sitemap has been revised (without breaking any links) to allow for more sections of documentation, the new sitemap provides a more hierarchical approach to the documentation which should make it easier to find what you're looking for quickly.

Playground v3

Over the past year, the playground has jumped in leaps and bounds - you can find out all of the features and changes to
TypeScript's interactive code explorer in it's own post coming soon.

However, the summary:

Sharable URLs are compressed to make sure they're not too long
There is a comprehensive set of examples teaching TypeScript in the Playground
Options from the tsconfig.json have explanations
The you can resize the sidebar
You can write in JS or TS, and see the .js or .d.ts outputs
Errors show in the sidebar
Types get downloaded from npm
The Playground can be extended by user plugins

Here's an example plugin which adds Clippy to the Playground:

Documentation

Handbook v1.5

The new handbook has a different structure. The previous handbook was a single section of the website, the new site features a lot more documentation pages and splits the handbook into three main sections:

Intros to TypeScript - which help you get an understanding of the language based on different backgrounds
Handbook - the 'read from a-z' of TypeScript to get a better understanding of the language primitives
Handbook Reference - singular deep dives into a particular topic

This split is especially helpful when starting to learn TypeScript, as it provides a focused track to learn. Then later, as you need particular techniques, there are reference docs which explore a topic in more depth.

Compiler-Checked Samples

We're moving more and more of our code samples to use a new TypeScript markup format called twoslash. Twoslash code samples use the TypeScript compiler to generate accurate error messages, get compiler outputs, and query hover tooltips for quick-info. This information can then be rendered in a a static page for code samples.

With this technique we can be certain that our code samples stay accurate and up-to-date as we work on the TypeScript compiler.

TSConfig Updates

One of the biggest areas for improvement was our documentation for the collection of over 100 compiler flags. The new TypeScript website includes a long-form description for every flag and examples are compiler-backed. This means we can be sure that the examples show exactly what happens when a particular config is changed.

Accessibility

The new website has been built with accessibility auditing happening on CI from day one.

To give a sense of the support matrix, here's what we account for with each page:

JavaScript being disabled
Keyboard-only navigation
Text-to-Speech users
Cookies/Local Storage being denied
A focused mobile navigation design
Light and Dark OS mode support, with a user-preference switcher

Localization

Anyone can learn to code, but adding the extra barrier of being proficient in English to master a programming language is a worry. We're a small compiler team, and wanted to provide the infrastructure to enable others to localize our site. Every section of the new site is built with multi-language support in mind.

We've gotten far on the translations for Chinese, Japanese, Portuguese and Spanish - you can see how far along they are via these GitHub issues. If you're interested in helping out, come and say hi in the TypeScript Community Discord.

Try it today

The new site was started exactly a year ago, getting here took over 1600 commits and received contributions from over 100 people. You can read more about the motivations for how the site was designed and architected in the "Web Infra Updates" GitHub issue.

With that said, we're always open to feedback and there's a lot of space for improvement now that everyone can provide some fresh perspective.

Give the new site a shot:

If you're interested in seeing the great localization work:

Let people own a subset of your repo

Orta — Thu, 13 Aug 2020 17:59:11 +0000

My Workflow

The Action: code-owner-self-merge

Using the CODEOWNERS format (a set of globs, then a set of GitHub usernames) you can define areas in a codebase which gives people the right to merge PRs which just affect their spaces.

Submission Category:

Maintainer Must-Haves

Yaml File or Link to Code

orta / code-owner-self-merge

A GitHub Action for letting CODEOWNERS merge PRs via green PR reviews

A GitHub action that lets code-owners merge PRs via a comment.

This action uses the standardized structure of a CODEOWNERS file to handle the access controls.

A simple example

So, with this file at: .github/CODEOWNERS:

README.md @orta

If a PR contained only a change to the README.md - this action would say that "@orta has the ability to merge by commenting 'LGTM'".

Then, when/if this happens the GitHub Action will merge for you.

A real-world example

.github/CODEOWNERS:

# Collaborators for Japanese Translation of the Website
packages/playground-examples/copy/ja/** @sasurau4
 @quramy
 @naturalclar
 @Takepepe @orta

packages/tsconfig-reference/copy/ja/** @sasurau4
 @quramy
 @naturalclar
 @Takepepe @orta

packages/typescriptlang-org/src/copy/ja/** @sasurau4
 @quramy
 @naturalclar
 @Takepepe @orta

packages/documentation/copy/ja/** @sasurau4
 @quramy
 @naturalclar
 @Takepepe @orta

This allows any of @sasurau4, @Quramy, @Naturalclar, @Takepepe or @orta to merge PRs which affect their areas of the translation process in the TypeScript Website repo.

Setting It Up

You want a…

View on GitHub

name: Codeowners merging
on:
  pull_request_target:
  issue_comment: { types: created }

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v1
    - name: Run Codeowners merge check
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      uses:  orta/code-owner-self-merge@v1

Additional Resources / Info

This is being used in the new TypeScript Website, to give translators access to merge PRs to their language: https://github.com/microsoft/TypeScript-Website/pull/899