How Definitely Typed Changed TypeScript Forever
Subtitles
Show
That's a good part of the project that you can just come and contribute and that's why actually there are so many people that contribute.
I mean I have to say there is something cute and and amazing about the passion for I think it's only developers with passion that can be like yeah I'm just going to spend all my free time on keeping types for everybody you know it's um I can see it being rewarding and relaxing at the same time.
I actually introduced flow to the project.
I didn't ask Typescript.
Yeah, I I was like I don't want to be this guy that oh I'm with the TypeScript guy so you will use TypeScript.
I investigated thoughts that flow is better at this point.
It it probably was like I I think my decision back then was okay.
You said that early on Typescript like the core concept of Typescript and I never thought about it this way was that it was providing definition files to existing code letting you enhance that code with types.
Is this the correct way to think about TypeScript from the mental model perspective uh like you said or like that was just how it all started?
It's actually more how it how it ended because to be uh to remind you if you're mentioning 2016 to tell you what happened in 2012.
Uh so the situation with JavaScript is pretty dire at this point.
I think ES5 was released and this is like the most minor release you could think of.
10 years after the previous release and it's such a minor release and I know I definitely was thinking oh man if uh this is the the language I will be using it better move faster than what's [Music] happening react Universe on air your go-to podcast for all things crossplatform hello everybody my name is Mike I'm CTO and founder at Goldstack And today with me is a very special guest that works with me at Costak
I mean I have to say there is something cute and and amazing about the passion for I think it's only developers with passion that can be like yeah I'm just going to spend all my free time on keeping types for everybody you know it's um I can see it being rewarding and relaxing at the same time.
I actually introduced flow to the project.
I didn't ask Typescript.
Yeah, I I was like I don't want to be this guy that oh I'm with the TypeScript guy so you will use TypeScript.
I investigated thoughts that flow is better at this point.
It it probably was like I I think my decision back then was okay.
You said that early on Typescript like the core concept of Typescript and I never thought about it this way was that it was providing definition files to existing code letting you enhance that code with types.
Is this the correct way to think about TypeScript from the mental model perspective uh like you said or like that was just how it all started?
It's actually more how it how it ended because to be uh to remind you if you're mentioning 2016 to tell you what happened in 2012.
Uh so the situation with JavaScript is pretty dire at this point.
I think ES5 was released and this is like the most minor release you could think of.
10 years after the previous release and it's such a minor release and I know I definitely was thinking oh man if uh this is the the language I will be using it better move faster than what's [Music] happening react Universe on air your go-to podcast for all things crossplatform hello everybody my name is Mike I'm CTO and founder at Goldstack And today with me is a very special guest that works with me at Costak
Boris.
Boris, nice to meet you in person, let's say.
And I'm super excited for this podcast today.
Nice to meet you.
Cool.
Yeah.
So the the title for today's coffee talk is pretty, I would say, unexpected.
It is the story behind Definitely Typed.
And we're going to talk about everything Typescript related.
And I guess for people definitely type may seem like something they know or they don't but for sure they know that those packages from npm that start with the at types.
So Boris I'm very interested about your background and how it all started and how did you even get involved in Typescript?
I think that's been like eight years ago.
So we are due for a bit of history.
Oh yeah.
Yeah.
It's very historic topic because it has been so long ago.
Actually I had to revisit a lot of uh the information to remember what I would say and it turns out it's actually from 2012 so more than 12 years ago very long time ago.
Yeah.
Yeah.
So I am developer.
Yeah I'm developer would be very weird if I wasn't to be evol but also back then I was also I was coding since I was 9 10 years old.
So even back then I was very deep into coding and to tell you some dates uh because again I read them.
So TypeScript was released on October 1st 2012 that's version 0.
8 the first public version and definitely type the first commit is 5 days later.
So I guess we'll go into details why uh so fast but yeah it's actually very long.
The first mover is advantage I guess.
I mean that's why my very first question to you is like how did you find out about Typescript and how did it happen so that 5 days later you were already sitting on this project.
Yeah.
So for some people it might TypeScript might be more of a new thing because now it's very established but previously because it's coming from Microsoft everything
Boris, nice to meet you in person, let's say.
And I'm super excited for this podcast today.
Nice to meet you.
Cool.
Yeah.
So the the title for today's coffee talk is pretty, I would say, unexpected.
It is the story behind Definitely Typed.
And we're going to talk about everything Typescript related.
And I guess for people definitely type may seem like something they know or they don't but for sure they know that those packages from npm that start with the at types.
So Boris I'm very interested about your background and how it all started and how did you even get involved in Typescript?
I think that's been like eight years ago.
So we are due for a bit of history.
Oh yeah.
Yeah.
It's very historic topic because it has been so long ago.
Actually I had to revisit a lot of uh the information to remember what I would say and it turns out it's actually from 2012 so more than 12 years ago very long time ago.
Yeah.
Yeah.
So I am developer.
Yeah I'm developer would be very weird if I wasn't to be evol but also back then I was also I was coding since I was 9 10 years old.
So even back then I was very deep into coding and to tell you some dates uh because again I read them.
So TypeScript was released on October 1st 2012 that's version 0.
8 the first public version and definitely type the first commit is 5 days later.
So I guess we'll go into details why uh so fast but yeah it's actually very long.
The first mover is advantage I guess.
I mean that's why my very first question to you is like how did you find out about Typescript and how did it happen so that 5 days later you were already sitting on this project.
Yeah.
So for some people it might TypeScript might be more of a new thing because now it's very established but previously because it's coming from Microsoft everything
that comes from Microsoft is a little bit more towards people that are already in the Microsoft ecosystem and other people are very skeptical.
That's actually something to be noted back then TypeScript was not just uh a super success immediately.
People were we don't need types they would even we don't need JavaScript.
Most people didn't even want to type write JavaScript, you know, but I was doing a lot of C# before that.
So, I was very familiar with what's coming from Microsoft and I was doing already a lot of JavaScript.
I was front-end developer like I I decided okay so there this front- end development will be big hopefully and all people that are doing JavaScript are just hackers kind of like there is no still nothing serious there.
So there's an opportunity and I was doing a lot of JavaScript and I wasn't loving it.
I hoped that Microsoft just make C compile to JavaScript and call it a day, you know.
And yeah, when they announced TypeScript, it was kind of clear that it's a good idea.
Like it was unclear if it will be a big idea in the future, but it was clear it's a good idea.
I just like literally they announced it.
I tried it out the first day immediately and honestly it was obvious what's missing like uh it is giving you types but there are a ton of libraries that exist out there and none of them have types because they're in JavaScript.
So the very missing part is actually types for these libraries.
And what Microsoft actually have added obviously in anticipating that was that uh they have created this definition files that are like external to the libraries that you can just add somewhere somehow you can write them yourself and they add types to JavaScript libraries and that was the mechanism to actually be in the typed world kind of.
That's interesting you
That's actually something to be noted back then TypeScript was not just uh a super success immediately.
People were we don't need types they would even we don't need JavaScript.
Most people didn't even want to type write JavaScript, you know, but I was doing a lot of C# before that.
So, I was very familiar with what's coming from Microsoft and I was doing already a lot of JavaScript.
I was front-end developer like I I decided okay so there this front- end development will be big hopefully and all people that are doing JavaScript are just hackers kind of like there is no still nothing serious there.
So there's an opportunity and I was doing a lot of JavaScript and I wasn't loving it.
I hoped that Microsoft just make C compile to JavaScript and call it a day, you know.
And yeah, when they announced TypeScript, it was kind of clear that it's a good idea.
Like it was unclear if it will be a big idea in the future, but it was clear it's a good idea.
I just like literally they announced it.
I tried it out the first day immediately and honestly it was obvious what's missing like uh it is giving you types but there are a ton of libraries that exist out there and none of them have types because they're in JavaScript.
So the very missing part is actually types for these libraries.
And what Microsoft actually have added obviously in anticipating that was that uh they have created this definition files that are like external to the libraries that you can just add somewhere somehow you can write them yourself and they add types to JavaScript libraries and that was the mechanism to actually be in the typed world kind of.
That's interesting you
mentioned it.
I mean I have so many questions but the first one I guess would be when I was working with React Native that was back in 2016.
I am 80 to 90% sure that I haven't heard about Typescript back then.
I think I only learned about Typescript sometime you know year after starting React Native.
maybe 2016ish and obviously React Native was a flow uh based framework back then and for the readers flow is like sort of Facebook's way to provide types for JavaScript which is sort of totally different I guess from the conceptual perspective than Typescript and it it is also Okamel based so I guess that adds another layer of complexity when it comes to contributing to it and I'm sure you had a lot of discussions early on and I don't know if you know the sort of motivation behind Typescript and why it was Typescript maybe instead of Flow put to another extreme but I'm sure there were a lot of developers early on that were you know just sort of curious about this versus flow and I'm curious what you think and if you remember any of these uh sort of discussions and what was the conclusion did Typescript feel more like you know like what was the benefit for for for you and for everybody using TypeScript overflow FL back then.
Yeah, good to mention flow because I actually my first project in React Native, I'm not sure if it's also around your time.
It was long time ago, 8 years.
So maybe about your time or later, but I actually introduced flow to the project.
I didn't script.
Yeah, I was like I don't want to be this guy that oh I'm with the TypeScript guy so you will use TypeScript.
I investigated thought that flow is better at this point.
It probably was like I think my decision back then was okay but I think Typescript won because Typescript is at least better in many aspects and also
I mean I have so many questions but the first one I guess would be when I was working with React Native that was back in 2016.
I am 80 to 90% sure that I haven't heard about Typescript back then.
I think I only learned about Typescript sometime you know year after starting React Native.
maybe 2016ish and obviously React Native was a flow uh based framework back then and for the readers flow is like sort of Facebook's way to provide types for JavaScript which is sort of totally different I guess from the conceptual perspective than Typescript and it it is also Okamel based so I guess that adds another layer of complexity when it comes to contributing to it and I'm sure you had a lot of discussions early on and I don't know if you know the sort of motivation behind Typescript and why it was Typescript maybe instead of Flow put to another extreme but I'm sure there were a lot of developers early on that were you know just sort of curious about this versus flow and I'm curious what you think and if you remember any of these uh sort of discussions and what was the conclusion did Typescript feel more like you know like what was the benefit for for for you and for everybody using TypeScript overflow FL back then.
Yeah, good to mention flow because I actually my first project in React Native, I'm not sure if it's also around your time.
It was long time ago, 8 years.
So maybe about your time or later, but I actually introduced flow to the project.
I didn't script.
Yeah, I was like I don't want to be this guy that oh I'm with the TypeScript guy so you will use TypeScript.
I investigated thought that flow is better at this point.
It probably was like I think my decision back then was okay but I think Typescript won because Typescript is at least better in many aspects and also
just Microsoft wants it to support it like it's very clear that they are behind it full like they're just behind the language very like they use it they put a lot of resources while actually flow just I mean several years ago after I started using it.
They already announced, okay, we uh from Facebook like they announced we're gonna use it mostly for our stuff and if you want to use it, use it, but we're not gonna like support you.
And I think you know what made me excited about Typescript was the sort of overall feeling that it was just I would say more traditional looking at least from the types perspective.
I think the syntax was more like Java or like you know just kind of more similar to what I'm let's say was used from other languages whereas flow with the dollar sign and all the different things uh was slightly different.
So I guess that was one thing.
But the other one, I'm not sure if you've run into this as well early on, was that flow had this sort of bad reputation for just accidentally stopping to work and you would immediately you would accidentally realize it was not providing the insights whereas Typescript just felt more sort of rigid in that sense.
Yeah, Typescript for sure the runtime is very focused on providing tooling.
There is actually an interesting part that around version 1.
2 they re uh re rewrite actually the code from something that is pretty cool to write like full classes and stuff to something that is actually efficient to run as tooling in IDE.
I think that flow is more focused on like scale and basically their stuff like Facebook stuff.
It's not like if Facebook wanted for flow to win kind of I think they could make it.
it's not that broken or anything like that is obviously wrong with it but obviously there can be only one kind of situation there is no point in having two
They already announced, okay, we uh from Facebook like they announced we're gonna use it mostly for our stuff and if you want to use it, use it, but we're not gonna like support you.
And I think you know what made me excited about Typescript was the sort of overall feeling that it was just I would say more traditional looking at least from the types perspective.
I think the syntax was more like Java or like you know just kind of more similar to what I'm let's say was used from other languages whereas flow with the dollar sign and all the different things uh was slightly different.
So I guess that was one thing.
But the other one, I'm not sure if you've run into this as well early on, was that flow had this sort of bad reputation for just accidentally stopping to work and you would immediately you would accidentally realize it was not providing the insights whereas Typescript just felt more sort of rigid in that sense.
Yeah, Typescript for sure the runtime is very focused on providing tooling.
There is actually an interesting part that around version 1.
2 they re uh re rewrite actually the code from something that is pretty cool to write like full classes and stuff to something that is actually efficient to run as tooling in IDE.
I think that flow is more focused on like scale and basically their stuff like Facebook stuff.
It's not like if Facebook wanted for flow to win kind of I think they could make it.
it's not that broken or anything like that is obviously wrong with it but obviously there can be only one kind of situation there is no point in having two
standards for sure.
Yeah.
And so I guess you sort of briefly highlighted this, but you said that early on Typescript like the core concept of TypeScript and I never thought about it this way was that it was providing definition files to existing code letting you enhance that code with types which I never thought about it this way.
I always thought Typescript is just basically JavaScript with types and I'm I usually write them in line but that there is obviously the definition file you can provide um you know sort of together with the code.
Is this the correct way to think about Typescript from the mental model perspective uh like you said or like that was just how it all started?
It's actually more how it ended because to remind you if you're mentioning 2016 uh to tell you what happened in 2012.
So the situation with JavaScript is pretty dire.
Like at this point I think ES5 was released and this is like the most minor release you could think of.
Yeah.
So 10 years after the previous release, it's such a minor release and I know I definitely was thinking oh man if uh this is the language I will be using it better move faster than what's happening.
So TypeScript initially was actually two things very strongly two things in one.
One was definitely added types which is what is happening right now was the power of it but another one was supporting new functionality that is that would be coming to JavaScript at some point but definitely not coming.
you could use already classes and whatever things that you couldn't actually use in pure JavaScript at this point.
Basically, all of these things were added to ES 2015 which obviously was a few years later and obviously until it proliferates to all the browsers and so on.
So another very important part was just using modern
Yeah.
And so I guess you sort of briefly highlighted this, but you said that early on Typescript like the core concept of TypeScript and I never thought about it this way was that it was providing definition files to existing code letting you enhance that code with types which I never thought about it this way.
I always thought Typescript is just basically JavaScript with types and I'm I usually write them in line but that there is obviously the definition file you can provide um you know sort of together with the code.
Is this the correct way to think about Typescript from the mental model perspective uh like you said or like that was just how it all started?
It's actually more how it ended because to remind you if you're mentioning 2016 uh to tell you what happened in 2012.
So the situation with JavaScript is pretty dire.
Like at this point I think ES5 was released and this is like the most minor release you could think of.
Yeah.
So 10 years after the previous release, it's such a minor release and I know I definitely was thinking oh man if uh this is the language I will be using it better move faster than what's happening.
So TypeScript initially was actually two things very strongly two things in one.
One was definitely added types which is what is happening right now was the power of it but another one was supporting new functionality that is that would be coming to JavaScript at some point but definitely not coming.
you could use already classes and whatever things that you couldn't actually use in pure JavaScript at this point.
Basically, all of these things were added to ES 2015 which obviously was a few years later and obviously until it proliferates to all the browsers and so on.
So another very important part was just using modern
features of JavaScript inside.
They were very um intentional.
Actually, another reason why they kind of won because they weren't too revolutionary.
Basically, the types are kind of an add-on.
They're designed in a way that you can strip them out.
And the new features are not also too revolutionary in tune uh experimental.
They're just what the JavaScript like the community or the what is planned for JavaScript actually.
and they they're very judicial about what would they add like there is nothing to create.
I think it is it is definitely getting closer to that these days now that TypeScript is sort of uh moving towards deprecating all non-standard features right like the enums and and and and we now have this flag in the config which is you know just using types that can be stripped out which is nicely integrated with NodeJS the latest flag I also seen the demo of somebody using a TypeScript with the script uh types directly in a browser which is also very Good.
So I think the the sort of current situation of the project is very close or closely moving towards that vision that you just described.
So uh sort of coming back to the definitely typed here is the uh sort of repo that I'm looking at and and and I just wanted to show it to everybody uh that is you know listening to us on YouTube if not you can uh go to YouTube and you will see what we're talking about.
So this is the repo where we have all the types and I think the very first question I have to you is where does the idea for this come from and did you even like consult this with somebody?
I mean it's it's like okay I decide that we're going to enhance the types with the definitions repo and like did you get inspiration from I don't know Ruby or homebrew and sort of the idea for a centralized repo came from that place or
They were very um intentional.
Actually, another reason why they kind of won because they weren't too revolutionary.
Basically, the types are kind of an add-on.
They're designed in a way that you can strip them out.
And the new features are not also too revolutionary in tune uh experimental.
They're just what the JavaScript like the community or the what is planned for JavaScript actually.
and they they're very judicial about what would they add like there is nothing to create.
I think it is it is definitely getting closer to that these days now that TypeScript is sort of uh moving towards deprecating all non-standard features right like the enums and and and and we now have this flag in the config which is you know just using types that can be stripped out which is nicely integrated with NodeJS the latest flag I also seen the demo of somebody using a TypeScript with the script uh types directly in a browser which is also very Good.
So I think the the sort of current situation of the project is very close or closely moving towards that vision that you just described.
So uh sort of coming back to the definitely typed here is the uh sort of repo that I'm looking at and and and I just wanted to show it to everybody uh that is you know listening to us on YouTube if not you can uh go to YouTube and you will see what we're talking about.
So this is the repo where we have all the types and I think the very first question I have to you is where does the idea for this come from and did you even like consult this with somebody?
I mean it's it's like okay I decide that we're going to enhance the types with the definitions repo and like did you get inspiration from I don't know Ruby or homebrew and sort of the idea for a centralized repo came from that place or
how did you land on this idea in first place?
The idea was actually quite obvious when you start using the language.
So, TypeScript actually with the distribution came with several definitions of things but like five files or something.
It was coming obviously with the DOM definitions some basic for jQuery obviously you would use this maybe basic for express but basically that was it and when you try them obviously it's very useful immediately you're seeing the help you're getting from types and basically kind of a documentation almost of the code you're working with but also you start using any other library and you see that it's not there so immediately just for fun maybe I was definitely more of a beginner front-end developer Like I was probably two years into front end and I was learning a lot of the libraries and I was like okay this this will be fun to create at least few definitions and after creating a few once I I was okay this will be a good idea to just have a lot of definitions for the popular libraries just like that and and basically the idea is kind of obvious you need that someone has to do that and TypeScript is not just jumping into super popularity there is not huge competition there a few other guys that had like oh here are these three or four definitions in this uh repo here are these two or three in another and I just created started for a few months like crazy guy created 5000 definitions and one of them created a pull request for his he said okay obviously this is the repo that will be some of them joined and so on.
Yeah, you won the initial competition by persistence and just doing many of them.
And uh where did you get the idea for the initial set of definitions?
Is just your personal projects or you were like getting feedback from some other people using
The idea was actually quite obvious when you start using the language.
So, TypeScript actually with the distribution came with several definitions of things but like five files or something.
It was coming obviously with the DOM definitions some basic for jQuery obviously you would use this maybe basic for express but basically that was it and when you try them obviously it's very useful immediately you're seeing the help you're getting from types and basically kind of a documentation almost of the code you're working with but also you start using any other library and you see that it's not there so immediately just for fun maybe I was definitely more of a beginner front-end developer Like I was probably two years into front end and I was learning a lot of the libraries and I was like okay this this will be fun to create at least few definitions and after creating a few once I I was okay this will be a good idea to just have a lot of definitions for the popular libraries just like that and and basically the idea is kind of obvious you need that someone has to do that and TypeScript is not just jumping into super popularity there is not huge competition there a few other guys that had like oh here are these three or four definitions in this uh repo here are these two or three in another and I just created started for a few months like crazy guy created 5000 definitions and one of them created a pull request for his he said okay obviously this is the repo that will be some of them joined and so on.
Yeah, you won the initial competition by persistence and just doing many of them.
And uh where did you get the idea for the initial set of definitions?
Is just your personal projects or you were like getting feedback from some other people using
TypeScript that hey this would be pretty cool.
Just whatever was popular or interesting for me I was adding and quickly other pull requests from other people.
Yeah.
Nice.
So I have to say I always took this repo for granted and I never thought about how it works.
I I I would usually just npm at at types slash and and by the way this is a very very good organization name on npm.
Was it just available back then or did you have to reach out to somebody?
Yeah.
Okay.
So to tell you quickly the history and what's the actual status of the library?
Yeah.
So the initial I I looked to remind myself if what was even the actual facts.
I looked to the commits and seems like the first few hundred commits I was just adding more and more uh on my own.
Then for several years I was literally reviewing hundreds and hundreds of pull requests merging of other people.
So just to clarify there are a lot of active contributors now and even back then quickly it become popular and this types thing with npm definitely did come later the first version was just the repo you could clone it and because types are not that big you know I mean it's obviously not optimal like even back then it's not optimal but also it's not complicated you know you clone it maybe it's few megabytes even hundreds of megabytes is better than inventing a new system.
Mhm.
At this point, but later actually at some several years later actually this types thing came from Microsoft because they uh we quickly got contributors also from Microsoft and like several years in the project you can think me of just one of the guys like definitely nothing special about me because it's very kind of horizontal um structure.
It's not too complicated as a project, you know, like there doesn't need to be some leader that says this will happen or this will
Just whatever was popular or interesting for me I was adding and quickly other pull requests from other people.
Yeah.
Nice.
So I have to say I always took this repo for granted and I never thought about how it works.
I I I would usually just npm at at types slash and and by the way this is a very very good organization name on npm.
Was it just available back then or did you have to reach out to somebody?
Yeah.
Okay.
So to tell you quickly the history and what's the actual status of the library?
Yeah.
So the initial I I looked to remind myself if what was even the actual facts.
I looked to the commits and seems like the first few hundred commits I was just adding more and more uh on my own.
Then for several years I was literally reviewing hundreds and hundreds of pull requests merging of other people.
So just to clarify there are a lot of active contributors now and even back then quickly it become popular and this types thing with npm definitely did come later the first version was just the repo you could clone it and because types are not that big you know I mean it's obviously not optimal like even back then it's not optimal but also it's not complicated you know you clone it maybe it's few megabytes even hundreds of megabytes is better than inventing a new system.
Mhm.
At this point, but later actually at some several years later actually this types thing came from Microsoft because they uh we quickly got contributors also from Microsoft and like several years in the project you can think me of just one of the guys like definitely nothing special about me because it's very kind of horizontal um structure.
It's not too complicated as a project, you know, like there doesn't need to be some leader that says this will happen or this will
not happen or something like that.
So, a lot of people actually got involved and at some point uh we actually had some um something like npm custom made by one of the contributors.
Pretty well done.
It was called tsd.
Even back then I was wondering who is this?
So, this is where tsd comes from cuz I do see this every once in a while or maybe I confuse it with some something else, but I think I've seen tsd somewhere like lately and I was like, "Okay, this is yet another build system I've never heard of.
" Probably it's not that because it's not that popular anymore.
But, but yeah, that that was for me it was radical.
I was thinking about uh package managers like something that few people write and I mean nowadays obviously everyone has a bundler and a packager but back then I was like okay that's too radical and then another guy actually created another better packager that's what's called typings but it was more distributed in theory sounded much better but uh actually Microsoft was heavily involved and it they had very like high stakes if that definite step will work for them because they actually integrated quite quickly the types from there in Visual Studio.
So it would download I'm not sure how it works right now but at least back then it would download the types automatically for you and give you that way the uh hints but they actually got involved.
They so this typing thing types prefix is actually coming from a system that they created that is automatically being run and published to npm.
Basically they uh decided that any more complicated system is too complicated but also you can't work with just a a whole one repo that basically it's it's using the GitHub like every system in GitHub you can use but also obviously it's not enough for you're listening to React Universe on
So, a lot of people actually got involved and at some point uh we actually had some um something like npm custom made by one of the contributors.
Pretty well done.
It was called tsd.
Even back then I was wondering who is this?
So, this is where tsd comes from cuz I do see this every once in a while or maybe I confuse it with some something else, but I think I've seen tsd somewhere like lately and I was like, "Okay, this is yet another build system I've never heard of.
" Probably it's not that because it's not that popular anymore.
But, but yeah, that that was for me it was radical.
I was thinking about uh package managers like something that few people write and I mean nowadays obviously everyone has a bundler and a packager but back then I was like okay that's too radical and then another guy actually created another better packager that's what's called typings but it was more distributed in theory sounded much better but uh actually Microsoft was heavily involved and it they had very like high stakes if that definite step will work for them because they actually integrated quite quickly the types from there in Visual Studio.
So it would download I'm not sure how it works right now but at least back then it would download the types automatically for you and give you that way the uh hints but they actually got involved.
They so this typing thing types prefix is actually coming from a system that they created that is automatically being run and published to npm.
Basically they uh decided that any more complicated system is too complicated but also you can't work with just a a whole one repo that basically it's it's using the GitHub like every system in GitHub you can use but also obviously it's not enough for you're listening to React Universe on
air your go-to podcast for all things crossplatform with React and React Native I do have some interesting things to show uh while you for uh giving us this explanation.
I did find some stuff.
So as you can see you are you know like you say there is a bunch of different contributors ever since and everybody has slightly different timeline.
Uh but you know on a grand scheme of things that diagram may look like a not that many contributions because the graph is small but it is 700 commits so it is actually quite a lot especially early on and I did find the very first commit which was not easy.
uh because I had to click like 50 times to pagenate back to the very first comet.
So I can see this is true initial comet just to read me.
Uh that's what it is.
Um so basically that's pretty interesting and like you say these days there is there is a lot of uh things going on and um I guess for people that are familiar they're mostly familiar with this which is the way you consume the types like you say came few years later or sometime later and it is a very nice automated way to publish those types I guess if I'm not wrong and and and you sort of highlighted this already uh the types are by default looked up by the TypeScript um sort of compiler.
You you don't have to specify the definitions location anymore to point to types prefix, right?
That is sort of working out of the box.
Yeah, that was added actually to TypeScript 2, which is probably 10 years ago, a long time ago.
That's part of the automation that Microsoft did.
They decided that yeah, if you have installed types like uh prefix types thingy in your project, obviously you want these types to be consumed automatically.
Yeah, that is pretty fun.
So I guess you know there is quite a lot of things uh in there actually when I always open up the
I did find some stuff.
So as you can see you are you know like you say there is a bunch of different contributors ever since and everybody has slightly different timeline.
Uh but you know on a grand scheme of things that diagram may look like a not that many contributions because the graph is small but it is 700 commits so it is actually quite a lot especially early on and I did find the very first commit which was not easy.
uh because I had to click like 50 times to pagenate back to the very first comet.
So I can see this is true initial comet just to read me.
Uh that's what it is.
Um so basically that's pretty interesting and like you say these days there is there is a lot of uh things going on and um I guess for people that are familiar they're mostly familiar with this which is the way you consume the types like you say came few years later or sometime later and it is a very nice automated way to publish those types I guess if I'm not wrong and and and you sort of highlighted this already uh the types are by default looked up by the TypeScript um sort of compiler.
You you don't have to specify the definitions location anymore to point to types prefix, right?
That is sort of working out of the box.
Yeah, that was added actually to TypeScript 2, which is probably 10 years ago, a long time ago.
That's part of the automation that Microsoft did.
They decided that yeah, if you have installed types like uh prefix types thingy in your project, obviously you want these types to be consumed automatically.
Yeah, that is pretty fun.
So I guess you know there is quite a lot of things uh in there actually when I always open up the
project and I try going to the types because this is where the things are.
It takes quite a while and like you cannot even see it all.
Like what is the best way to work with this?
Like how do we maintain it?
Like do you have it like cloned entirely and then like if yes, how big is that?
I mean that sounds like a lot of things.
Yeah, you clone it but yeah it's not that many.
I mean uh every so there are eight almost 9,000 folders there.
That's why GitHub is choking but they're not that big the folders themselves and a lot of it is automation.
So the first versions you can imagine was very simple.
You just get notifications on GitHub.
Okay, I need to fix or to review something.
But obviously at some scale and it was very early that scale it was already ignorable amount of notifications.
So basically there is a bot that goes and sees okay there is this thing that needs to be reviewed.
These are the contributors that contributed so many lines of code.
We'll email them something.
Hello nice.
So it's automated.
I was going to ask you how do you sort of keep up with the changes because you know we know that JavaScript is ever moving target and all these projects they may may not follow somewhere and they may break or may not and keeping the definitions outside is some sort of a um you know it puts a burden on you and like the whole crew to keep those up to date and I guess that seems like quite a challenge or quite a mess at a scale.
However, I have to say I've never run into any problems.
I mean, I worked with definitely type types and for some of the crazier projects that seem very unpopular, never had a single issue.
Never had a single issue.
Seems like a miracle to be honest that it was maintainable at such a scale.
So do you think is this because
It takes quite a while and like you cannot even see it all.
Like what is the best way to work with this?
Like how do we maintain it?
Like do you have it like cloned entirely and then like if yes, how big is that?
I mean that sounds like a lot of things.
Yeah, you clone it but yeah it's not that many.
I mean uh every so there are eight almost 9,000 folders there.
That's why GitHub is choking but they're not that big the folders themselves and a lot of it is automation.
So the first versions you can imagine was very simple.
You just get notifications on GitHub.
Okay, I need to fix or to review something.
But obviously at some scale and it was very early that scale it was already ignorable amount of notifications.
So basically there is a bot that goes and sees okay there is this thing that needs to be reviewed.
These are the contributors that contributed so many lines of code.
We'll email them something.
Hello nice.
So it's automated.
I was going to ask you how do you sort of keep up with the changes because you know we know that JavaScript is ever moving target and all these projects they may may not follow somewhere and they may break or may not and keeping the definitions outside is some sort of a um you know it puts a burden on you and like the whole crew to keep those up to date and I guess that seems like quite a challenge or quite a mess at a scale.
However, I have to say I've never run into any problems.
I mean, I worked with definitely type types and for some of the crazier projects that seem very unpopular, never had a single issue.
Never had a single issue.
Seems like a miracle to be honest that it was maintainable at such a scale.
So do you think is this because
of the all the automations you had there or maybe at the end of the day the JavaScript ecosystem is not that breaking on the sort of front end surface.
Yeah, all of what you mentioned I say is correct.
Definitely because you're defining the uh API surface level of the library, it breaks less often and it's usually documented in the decent libraries at least is documented that something doesn't work.
Usually the guys that write the types are people that are using the library currently and just are seeing either issues or uh just missing types.
And yeah, um it's not that hard.
It takes a lot of effort, but it's a combined effort.
The benefit is that it's relatively easy to get into writing types.
If someone is using a library that has no types, I would very much encourage them to try to write uh type definitions for that library.
It's not that hard.
That's interesting.
It's very useful.
It's very useful.
Yeah.
Did you have uh I mean I'm sure you had cases where people say I'm a package library author and I see my types are indefinitely typed but at some point I decide to migrate my project to typescript in first place which I think is happening even more often these days.
Were there cases where people would reach out and be like, can we move this out to my package because I want to take ownership of that and if yes, is this sort of a normal process that happens every once in a while for for definitely typed?
Yeah, it's normal.
But usually it sometimes might happen that uh the author would have a JavaScript project and would uh distribute types on his own and that would be a good I mean it will be okay idea but when they actually create a TypeScript project or migrate to Typescript then the best case is just to not actually not to not include because they are versioned and it's
Yeah, all of what you mentioned I say is correct.
Definitely because you're defining the uh API surface level of the library, it breaks less often and it's usually documented in the decent libraries at least is documented that something doesn't work.
Usually the guys that write the types are people that are using the library currently and just are seeing either issues or uh just missing types.
And yeah, um it's not that hard.
It takes a lot of effort, but it's a combined effort.
The benefit is that it's relatively easy to get into writing types.
If someone is using a library that has no types, I would very much encourage them to try to write uh type definitions for that library.
It's not that hard.
That's interesting.
It's very useful.
It's very useful.
Yeah.
Did you have uh I mean I'm sure you had cases where people say I'm a package library author and I see my types are indefinitely typed but at some point I decide to migrate my project to typescript in first place which I think is happening even more often these days.
Were there cases where people would reach out and be like, can we move this out to my package because I want to take ownership of that and if yes, is this sort of a normal process that happens every once in a while for for definitely typed?
Yeah, it's normal.
But usually it sometimes might happen that uh the author would have a JavaScript project and would uh distribute types on his own and that would be a good I mean it will be okay idea but when they actually create a TypeScript project or migrate to Typescript then the best case is just to not actually not to not include because they are versioned and it's
probably like his version five is JavaScript and his version six is TypeScript.
So we will keep the version 5x indefinitely typed and then six will no longer need the types because it's typescript and the types will be gotten directly from typescript like it's a really good uh thing that's happening right now that almost like not almost I think I've not seen any popular library that does not use typescript nowadays obviously there are because the amount of libraries that are covered by definitely typed is increasing so I guess there are more But anything that is worth it is actually using very very well using the features of TypeScript.
Not just that the the extension of the files are t is ts but they're using it very well.
Yeah but that is an interesting insight that the number of projects indefinitely typed is increasing.
I would say one would assume okay the types were are over Typescript has won.
it's it's now the default but seems like not necessarily the case.
Uh which I'm not sure what to think about but it's just an interesting observation I would say.
Yeah, there will always be these libraries I guess.
Yeah, they will never be rewritten and they will exist.
So yeah, if I understand right, it seems like the sort of way to manage such a large scale open source repo is primarily uh sort of automations is that and I'm I'm from what I'm hearing you had nice automations for uh releasing those types and for uh maintaining did I get it right that you had some automation to catch the inconsistencies and like track the latest releases and notify uh sort of interested parties.
Yeah.
Yeah.
Okay, that is pretty cool.
And uh what about contributions?
Um say uh you know we often have um you know getting started guides and stuff like that but every
So we will keep the version 5x indefinitely typed and then six will no longer need the types because it's typescript and the types will be gotten directly from typescript like it's a really good uh thing that's happening right now that almost like not almost I think I've not seen any popular library that does not use typescript nowadays obviously there are because the amount of libraries that are covered by definitely typed is increasing so I guess there are more But anything that is worth it is actually using very very well using the features of TypeScript.
Not just that the the extension of the files are t is ts but they're using it very well.
Yeah but that is an interesting insight that the number of projects indefinitely typed is increasing.
I would say one would assume okay the types were are over Typescript has won.
it's it's now the default but seems like not necessarily the case.
Uh which I'm not sure what to think about but it's just an interesting observation I would say.
Yeah, there will always be these libraries I guess.
Yeah, they will never be rewritten and they will exist.
So yeah, if I understand right, it seems like the sort of way to manage such a large scale open source repo is primarily uh sort of automations is that and I'm I'm from what I'm hearing you had nice automations for uh releasing those types and for uh maintaining did I get it right that you had some automation to catch the inconsistencies and like track the latest releases and notify uh sort of interested parties.
Yeah.
Yeah.
Okay, that is pretty cool.
And uh what about contributions?
Um say uh you know we often have um you know getting started guides and stuff like that but every
once in a while people just send pull requests anyway.
Do you remember any PRs in particular where you had to like you know reject something or maybe say hey this is low quality and like yeah anything that comes to your mind after all that time.
So, I don't actually have anything that interesting and that's I think a good point.
I have with other projects that are related and I know what you mean.
Uh, sometimes someone spent obviously a lot of effort on something and you just need to reject it or you know that you can spend the time to work him through the system.
But, uh, the good part about these types is that usually they're not that complicated to write.
uh as long as you want to spend the time you can probably write them and sometimes it just takes time to go through the whole documentation or the source code and see what's there and I mean it's very beginner friendly if someone is wondering if they should contribute they definitely should try that's very interesting so you did a lot of contributions uh very early on and sounds like you were happy with all the types ever since do you still maintain some relation with like is there a core team behind the project like do you guys still uh get in touch and and like if I would be interested like what's what's what's even on the road map for this project is it just you know tell me more about that that that's pretty interesting there are interestingly that we know each other almost um by just nicknames kind of because people come and go but because there are so many people but some of them are so dedicated Like the guy you will see currently at top uh contributor Wakame is his nickname is has been active for several years but like very very prolific at this point and just now it's not and so on.
I mean that's a good part of the
Do you remember any PRs in particular where you had to like you know reject something or maybe say hey this is low quality and like yeah anything that comes to your mind after all that time.
So, I don't actually have anything that interesting and that's I think a good point.
I have with other projects that are related and I know what you mean.
Uh, sometimes someone spent obviously a lot of effort on something and you just need to reject it or you know that you can spend the time to work him through the system.
But, uh, the good part about these types is that usually they're not that complicated to write.
uh as long as you want to spend the time you can probably write them and sometimes it just takes time to go through the whole documentation or the source code and see what's there and I mean it's very beginner friendly if someone is wondering if they should contribute they definitely should try that's very interesting so you did a lot of contributions uh very early on and sounds like you were happy with all the types ever since do you still maintain some relation with like is there a core team behind the project like do you guys still uh get in touch and and like if I would be interested like what's what's what's even on the road map for this project is it just you know tell me more about that that that's pretty interesting there are interestingly that we know each other almost um by just nicknames kind of because people come and go but because there are so many people but some of them are so dedicated Like the guy you will see currently at top uh contributor Wakame is his nickname is has been active for several years but like very very prolific at this point and just now it's not and so on.
I mean that's a good part of the
project that you can just come and contribute and that's why actually there are so many people that contribute.
I mean, I have to say there is something cute and and amazing about the passion for, you know, it's only I think it's only developers with passion that can be like, yeah, I'm just going to spend all my free time on keeping types for everybody, you know, it's um I can see it being rewarding and relaxing at the same time.
Cool.
Uh so, uh regarding the sort of uh project governance itself, uh you know, we did we discussed it's a lot of time.
you need a lot of time for this uh and and Microsoft's been using that.
Did you have any support from companies uh or sponsorships?
Uh how did you make it sustainable and any takeaways out of that?
So I would say it very much depends on project per project because I've definitely been other projects that this is very much a concern.
If it going to work, it has to either get sponsorship or something.
In this one, I would say almost everything was pretty chill.
Everything kind of just worked because there was uh such a clear benefits to just these types existing like almost everyone benefiting.
There is no necessarily like battles you don't need to win for this to exist instead of another project.
Also the other thing is you wouldn't necessarily get a big contract if this project wins like you know this is not some like state management library or enterprise whatever something that you will get clients based on that so we didn't actually ask for any money anyone especially initially because even back then I guess it's very weird also how you will get the money and then who gets the money especially the more people are involved it's tricky sometimes it's just better for people to work because they want to.
But definitely Microsoft put a
I mean, I have to say there is something cute and and amazing about the passion for, you know, it's only I think it's only developers with passion that can be like, yeah, I'm just going to spend all my free time on keeping types for everybody, you know, it's um I can see it being rewarding and relaxing at the same time.
Cool.
Uh so, uh regarding the sort of uh project governance itself, uh you know, we did we discussed it's a lot of time.
you need a lot of time for this uh and and Microsoft's been using that.
Did you have any support from companies uh or sponsorships?
Uh how did you make it sustainable and any takeaways out of that?
So I would say it very much depends on project per project because I've definitely been other projects that this is very much a concern.
If it going to work, it has to either get sponsorship or something.
In this one, I would say almost everything was pretty chill.
Everything kind of just worked because there was uh such a clear benefits to just these types existing like almost everyone benefiting.
There is no necessarily like battles you don't need to win for this to exist instead of another project.
Also the other thing is you wouldn't necessarily get a big contract if this project wins like you know this is not some like state management library or enterprise whatever something that you will get clients based on that so we didn't actually ask for any money anyone especially initially because even back then I guess it's very weird also how you will get the money and then who gets the money especially the more people are involved it's tricky sometimes it's just better for people to work because they want to.
But definitely Microsoft put a
lot of you could say contribution in terms of efforts.
A lot of uh their developers actually contributed a lot of the infrastructure work, a lot of just work like some of the contributors are Microsoft employees.
I guess some of them are working because they want to but some of them because they're paid.
So very organically uh the support came it just existed.
So we didn't need to invent a way to to create that support.
That makes sense.
So I guess we know everything uh about this project now.
And you know it's it's so interesting that I only found out about it when you sent me random pull request and I was like who's that guy?
And then I see uh the organization that sounds familiar and I'm like wow.
I mean, the second one was cold stuck when I realized, wow, uh, like that it's even more fun.
Uh, because it's always interesting to see our our faces in the wild.
So, I guess I'm I'm super excited that I found out about it because I think it's a great piece of history and, you know, I I think I I should thank you for making my life easier because it always works for me wonders and Typescript made my life way way easier.
I'm quite interested about, you know, like from pure Typescript perspective.
We already talked about it and I know you're a huge fan obviously as we all are, but what is the sort of best feature of it that you like or maybe the feature that you don't like the most?
Uh, if you could shoot some random examples of one of each, that would be great.
I'm I'm really interested from somebody who spends so much time in there what that feature would be.
So they actually uh the typescript team releases new versions very regularly.
So there are new features all the time just so if someone is a fan of just languages and types uh they should just very closely follow
A lot of uh their developers actually contributed a lot of the infrastructure work, a lot of just work like some of the contributors are Microsoft employees.
I guess some of them are working because they want to but some of them because they're paid.
So very organically uh the support came it just existed.
So we didn't need to invent a way to to create that support.
That makes sense.
So I guess we know everything uh about this project now.
And you know it's it's so interesting that I only found out about it when you sent me random pull request and I was like who's that guy?
And then I see uh the organization that sounds familiar and I'm like wow.
I mean, the second one was cold stuck when I realized, wow, uh, like that it's even more fun.
Uh, because it's always interesting to see our our faces in the wild.
So, I guess I'm I'm super excited that I found out about it because I think it's a great piece of history and, you know, I I think I I should thank you for making my life easier because it always works for me wonders and Typescript made my life way way easier.
I'm quite interested about, you know, like from pure Typescript perspective.
We already talked about it and I know you're a huge fan obviously as we all are, but what is the sort of best feature of it that you like or maybe the feature that you don't like the most?
Uh, if you could shoot some random examples of one of each, that would be great.
I'm I'm really interested from somebody who spends so much time in there what that feature would be.
So they actually uh the typescript team releases new versions very regularly.
So there are new features all the time just so if someone is a fan of just languages and types uh they should just very closely follow
this these.
So one feature that I like a lot and I think not enough developers know about it uh is something that is actually introduced long time ago.
It's called discriminated unions.
uh uh yeah so see it's not that uh crazy uh if you if you have to write libraries then you need to know kind of a lot of crazy typing things but so discriminated unions to explain what it is so usually a union would be you combine several different types and the value can be any one of these types uh so it's maybe result from maybe an API call or something obviously it can be an error and the form of an error result is different from uh an okay uh response.
But there is this thing that's called discriminator.
It's one value that depending on the value of that property.
So for example, imagine something is like status and the status is either okay or an error.
So if the status is okay then you have maybe data property that you can uh investigate.
But if it's an error, there is another property that is like status code, error code, something like that.
And the cool part about this once you write it, so if you handle the error initially like, oh, if status equals error or whatever, yeah, then TypeScript already knows that data is defined because we already handled the other case that it is not defined and you don't need to add these question marks and so on to pretend that.
Yeah.
So this is very TypeScript gets better and better at understanding what the library does at some more sophisticated level.
Yeah.
And the other cool part by the way is that libraries become better at not creating crazy stuff that TypeScript cannot understand.
And that's good for us and for everyone honestly.
Yeah.
I wanted to show everybody the the way the only way I know about discriminated unions lately
So one feature that I like a lot and I think not enough developers know about it uh is something that is actually introduced long time ago.
It's called discriminated unions.
uh uh yeah so see it's not that uh crazy uh if you if you have to write libraries then you need to know kind of a lot of crazy typing things but so discriminated unions to explain what it is so usually a union would be you combine several different types and the value can be any one of these types uh so it's maybe result from maybe an API call or something obviously it can be an error and the form of an error result is different from uh an okay uh response.
But there is this thing that's called discriminator.
It's one value that depending on the value of that property.
So for example, imagine something is like status and the status is either okay or an error.
So if the status is okay then you have maybe data property that you can uh investigate.
But if it's an error, there is another property that is like status code, error code, something like that.
And the cool part about this once you write it, so if you handle the error initially like, oh, if status equals error or whatever, yeah, then TypeScript already knows that data is defined because we already handled the other case that it is not defined and you don't need to add these question marks and so on to pretend that.
Yeah.
So this is very TypeScript gets better and better at understanding what the library does at some more sophisticated level.
Yeah.
And the other cool part by the way is that libraries become better at not creating crazy stuff that TypeScript cannot understand.
And that's good for us and for everyone honestly.
Yeah.
I wanted to show everybody the the way the only way I know about discriminated unions lately
uh was actually through using zot for a schema which obviously translates to typescript at the end of the day and the reason I know about it is when you are using uh openai for example structured outputs and you're passing z schema as a response you cannot have the top level union and you cannot even have union but what you can have is discriminated union and then the discriminator must be present as literal.
So that's how I know about it and it's pretty useful because then like you say when you do an if condition on status and you check for example if it's success automatically you have the the matching shape which is pretty exciting and uh makes it super useful.
For some reason, I'm never a fan of uh writing type assertions and usually when they don't work for me, I immediately realize that maybe I did something wrong with my types, especially when I'm, you know, sort of switch casing through the for the object.
So, that is pretty cool.
So, I guess I have to agree with you that this is one of the cool features and I can add one from my salad that I learned lately thanks to using ban.
I'm not sure exactly if this is the correct config field, but the one that lets me choose what are the package JSON fields to look up when resolving the file.
So I can for example specify that when you are importing a project you can look up uh you know from package JSON exports field when I have bun for example or source or react native use the file that is under that uh property rather than whatever would be used otherwise which is pretty cool in monor repo setups where you want to load packages uh from local uh file system rather than having to compile them.
Great.
So Boris I have to say thank you very much.
It's been a pleasure uh to have this throwback even even you know older than React Native
So that's how I know about it and it's pretty useful because then like you say when you do an if condition on status and you check for example if it's success automatically you have the the matching shape which is pretty exciting and uh makes it super useful.
For some reason, I'm never a fan of uh writing type assertions and usually when they don't work for me, I immediately realize that maybe I did something wrong with my types, especially when I'm, you know, sort of switch casing through the for the object.
So, that is pretty cool.
So, I guess I have to agree with you that this is one of the cool features and I can add one from my salad that I learned lately thanks to using ban.
I'm not sure exactly if this is the correct config field, but the one that lets me choose what are the package JSON fields to look up when resolving the file.
So I can for example specify that when you are importing a project you can look up uh you know from package JSON exports field when I have bun for example or source or react native use the file that is under that uh property rather than whatever would be used otherwise which is pretty cool in monor repo setups where you want to load packages uh from local uh file system rather than having to compile them.
Great.
So Boris I have to say thank you very much.
It's been a pleasure uh to have this throwback even even you know older than React Native
itself which is for many people I guess an ancient history and testament of how old are we these days even though we don't look like it in the camera flesh I hope uh so it's been fun I mean I'm super happy I guess we should now follow you on Twitter and follow you on GitHub and sort of be on YouTube oh yes exactly as you can see by his professional camera setup even more professional than this studio.
Boris, you're up to starting YouTube channel.
Tell us more about it.
Like what's the main theme going to be?
I have to.
The only reason I have to is because I need to justify to my wife the all the equipment I bought.
So I will Oh, I know this very well.
My wife always says, you know, now you got all this gear.
I just before you get another one, start using this one.
So I totally I totally get you.
Cool.
So in the details uh we will share all the details uh for Boris and also um you know stay tuned for for his upcoming YouTube channel.
I'm sure it will be great.
And before we wrap it up uh just a very quick announcement that React Universe Conf, a conference we organized here in Roswaf is starting to sort of shape up slowly and we have already announced uh the first round of speakers.
So grab your tickets while they're out there.
The early birds are waiting for you.
So if you want to meet me and hopefully Boris and the Colto stack team, see this office, maybe see the studio in person, React Universe Conf is the conference that you should get your tickets.
And yeah, see you in Roswav and thanks for listening and see you in the next episode.
[Music]
Boris, you're up to starting YouTube channel.
Tell us more about it.
Like what's the main theme going to be?
I have to.
The only reason I have to is because I need to justify to my wife the all the equipment I bought.
So I will Oh, I know this very well.
My wife always says, you know, now you got all this gear.
I just before you get another one, start using this one.
So I totally I totally get you.
Cool.
So in the details uh we will share all the details uh for Boris and also um you know stay tuned for for his upcoming YouTube channel.
I'm sure it will be great.
And before we wrap it up uh just a very quick announcement that React Universe Conf, a conference we organized here in Roswaf is starting to sort of shape up slowly and we have already announced uh the first round of speakers.
So grab your tickets while they're out there.
The early birds are waiting for you.
So if you want to meet me and hopefully Boris and the Colto stack team, see this office, maybe see the studio in person, React Universe Conf is the conference that you should get your tickets.
And yeah, see you in Roswav and thanks for listening and see you in the next episode.
[Music]
Timestamps
Show
Guests
Boris Yankov
Software Engineer
@
Callstack
Ever wondered why TypeScript feels so seamless with your favorite JavaScript libraries? It’s not just luck—it’s Definitely Typed, a project that plays a crucial role in enabling TypeScript developers to use JavaScript libraries with type safety and autocompletion.
In this Coffee Talk episode of React Universe On Air, Mike has invited Boris Yankov, the repository’s creator and long-time maintainer, to share the story of Definitely Typed. They discuss how this open-source repository became the backbone of type safety in TypeScript.
The full story of Definitely Typed
Here’s what you can expect from this episode:
- The early days of TypeScript—Boris takes us back to 2012, just after TypeScript's release. He discusses the challenges of building the first type definitions and how early contributions helped lay the foundation for the TypeScript ecosystem we know today.
- From passion project to Open Source giant—What began as a personal project quickly grew into a community-driven repository with thousands of contributors. Boris explains how automation and Microsoft’s support helped scale Definitely Typed from a niche tool to an open-source giant.
- TypeScript vs. Flow Mike and Boris discuss why TypeScript's pragmatic approach to type safety and strong backing from Microsoft led to its success over Flow. They talk about how Definitely Typed contributed to TypeScript's widespread adoption by offering robust type definitions for JavaScript libraries, establishing its place as the go-to choice for typed JavaScript.
- How Definitely Typed works—Boris provides a technical overview of how Definitely Typed integrates with NPM and TypeScript’s tooling, making type definitions accessible through the @types packages. He explains the automated publishing process and how contributors' updates are published to NPM, ensuring developers rarely encounter issues with type definitions in their projects.
- The open-source dynamics—Boris shares the human side of open source, discussing the project's organic collaboration model and why it doesn’t need a strict leadership structure. He also explains how new contributors can get started.
- Favorite TypeScript features—To wrap up, Boris and Mike share their favorite TypeScript features, such as Discriminated Unions, and offer development tips for working with type definitions.
Learn more about Definitely Typed
- Mike Grabowski on X, BlueSky, and GitHub
- Boris Yankov on X, BlueSky, and GitHub
- Definitely Typed homepage
- Definitely Typed repo
Launching or scaling an open-source project?
We help teams bring new open-source projects to life and grow them within the React Native space.
Let’s chat
//
Insights
Learn more about
Open Source
Here's everything we published recently on this topic.
//
Open Source
We can help you move
it forward!
At Callstack, we work with companies big and small, pushing React Native everyday.
React Native Development
Hire expert React Native engineers to build, scale, or improve your app, from day one to production.
React Development
Develop high-performance React applications with advanced patterns and scalable architectures.
React Compiler Implementation
Use React Compiler to achieve instant performance benefits in your existing applications.
React Native Trainings
Equip your team with React Native skills through tailored training sessions.
