← Software Engineering Daily
Software Engineering Daily
TypeScript ESLint with Josh Goldberg
00:56:29
TypeScript is a superset of JavaScript that adds static typing with optional type annotations. It was created at Microsoft and first released in 2012. TypeScript ESLint enables ESLint and Prettier to run on TypeScript code.
Loading summary
Transcript116 lines
- [00:00]
Josh Goldberg
TypeScript is a superset of JavaScript that adds static typing with optional type annotations. It was created at Microsoft and first released in 2012. TypeScript Eslint enables Eslint and prettier to run on TypeScript code. Josh Goldberg is a host for Software Engineering Daily, the author of Learning TypeScript by O'Reilly, and a Microsoft MVP. He's also a maintainer of TypeScript eSlint. In this episode, Josh speaks with Pavel Borkowski about the history of TypeScript, why it was created, some of its current limitations, the TypeScript ESLint project, and more. Pawel Burkowski is a tech lead and a software engineer with a background in launching products in startups and big companies. He's also the founder of flatsocial. Check out the Show Notes to follow Pawel on Twitter or LinkedIn or visit his personal website Pawel IO.
- [01:05]
Pavel Borkowski
Hi Josh, welcome to Software Engineering Daily.
- [01:08]
Josh Goldberg
Hey, thanks for having me.
- [01:09]
Pavel Borkowski
So let's start with the first question about your background a little bit more. How did you get into programming and what were your first steps in the world of building software?
- [01:18]
Josh Goldberg
So my dad was a computer science professor, which meant throughout high school, at least the first half, I didn't want to do anything involving computer science, but I was really into Photoshop and graphic design and I ended up wanting to make a website for myself. My little we called them forum signatures, little photoshopped images I made on the Internet. So I got into HTML and I took a Java class in high school and kind of fell in love with it. So I went to university for a four year computer science programming degree and haven't looked back since.
- [01:44]
Pavel Borkowski
So you had still some background from before, before you actually got to university. You tried coding before so it wasn't your first experience?
- [01:51]
Josh Goldberg
Yeah, yeah, I miss the days of being able to spend time photoshopping my friends faces onto animals. But I knew pretty quickly that coding was something that I really enjoyed and could make money off of.
- [02:00]
Pavel Borkowski
I still do the Photoshop part, but I don't advertise that on LinkedIn. Yeah, I love that. So you are the author of a book called Learning Types Prep that has been published by the famous Orally Media. So I think you're the best person to ask in this room what is Typescript?
- [02:16]
Josh Goldberg
Sure, Typescript is a typed superset of JavaScript. What that means is it's like the JavaScript language. It has all the stuff you know and quote love about JavaScript, but it also adds in a few things that make it a little easier to write a lot of JavaScript, it adds in syntax like a formal specification ish, where you can describe what shapes things are going to be like. If this function takes in an options object with certain properties or string or whatnot, and it provides a type checker, which is the thing that looks at your JavaScript and or TypeScript files with or without those nice types and type annotations. And it lets you know if you might have messed something up. Like if you say this function takes in a string but you passed a number, it can on the command line give you a report of that. Or in your editor it can give you little red squigglies explaining hey, you messed up. This is where you said it would be something else. So overall it's a nice way to write what is essentially JavaScript, but much better described with types and much better checked at development and build time.
- [03:12]
Pavel Borkowski
What's the story behind TypeScript? Because that's been created at Microsoft right at the moment I think it's more of an open source and community around this and I was wondering who decides at this point which direction TypeScript will evolve in and what's the decision process in that?
- [03:27]
Josh Goldberg
It's a good question. TypeScript is a Microsoft project. It always has been and for the foreseeable future will be. It was actually one of the first major open source projects to come out of Microsoft. It even predates GitHub being the common code platform for everyone to use for these things. So at the beginning TypeScript was one of several languages that was trying to work in that space of we're a really big company that's trying to build JavaScript applications like e.g. office on the web, word.office.com and JavaScript itself is God awful at the time at least and still to an extent today at say letting you write 1,000 files or 100,000 files, like if you change one file back in the day it was very difficult to know which files would be impacted, what are the type signature changes, what refactors or bugs would you have to work with. So Microsoft made that because they were trying to compete with things like Google Docs and other big web apps. And they found that they were used to the really nice development experience of Visual Studio with C on. Net and wanted that in JavaScript land. So these days it's still a Microsoft project. You know, the TypeScript team runs it, but it's open source on GitHub. They're extremely active. I've contributed as an external contributor, I've filed issues, sent pull requests and for the most part, they try to stick to just the types space. They don't really try to compete with what's getting added to JavaScript, like runtime features in JavaScript, but they do work pretty closely with TC39, the committee number 39. I don't know what the other 38 are that decides actual JavaScript to make sure that they're just working in the type space and not conflicting with JavaScript itself.
- [05:01]
Pavel Borkowski
I was wondering, for example, if you have TypeScript, then obviously JavaScript would be the dependency for TypeScript. So if something changes within the JavaScript world, then the TypeScript will have to follow in order to keep it consistent at the same time. So is it like a unidirectional decision process or is it them talking together? Because I think quite often we use those tools.
- [05:22]
Josh Goldberg
Yeah, nothing in tech is ever very formalized, exact process met. There are always wacky side conversations and whatnot. So I don't know exactly how intricate the TypeScript JavaScript TC39 relationship is. What I will say is that the TypeScript team makes a very strong effort to not get in the way of JavaScript. JavaScript is one of the most difficult languages to work on in modern times because it's in this bizarre, unique position where you can't break the web and you have to maintain backwards compatibility ad infinitum. You have to support IE9 for modern JavaScript features, or at least you have to support that you don't break Internet Explorer 9 running IE9 tailored websites. So as difficult as it is to write JavaScript, it would be that much more difficult if TypeScript got in the way and started introducing runtime stuff and polluting the namespaces. So for the most part, JavaScript adds runtime features and then TypeScript adds type system things like they very explicitly try to mostly innovate in the type space.
- [06:20]
Pavel Borkowski
Do you think that typescript maybe would ever go more into a standalone part to separate itself from JavaScript or.
- [06:28]
Josh Goldberg
I don't think so. There are some community projects that kind of take TypeScript and put it in a new fun place. For example, AssemblyScript is a really interesting one, where instead of compiling your TypeScript code down to JavaScript, it compiles it to webassembly bytecode equivalent. The target of this is that you can Write your nice TypeScript stuff, even use some TypeScript libraries, but then ship in WebAssembly. So the assembly script language is really cool. But the main goal of TypeScript is not to replace JavaScript. It's not the old Microsoft, embrace, extend, extinguish. If anyone remembers that horrible mantra from back in the day, it's that there is an existing JavaScript ecosystem. We're stuck with it. We love it. It's got its quirks, it's got its beauty. And typescript is a way to make that ecosystem more pleasant to deal with, more pleasant to write code in. If you were to kind of separate TypeScript and JavaScript, you'd lose the beauty and the power of the JavaScript ecosystem and would make TypeScript much less valuable as a language.
- [07:23]
Pavel Borkowski
And if you could change or improve anything about TypeScript itself, what that would be? What do you think is there to be still improved?
- [07:31]
Josh Goldberg
There's always stuff to be done. The typescript issues on GitHub are numerous. I think there are over 5,000 of them. For me, as someone who tries to teach people TypeScript and is focused on tooling around it to make it easier to use, the biggest gripe, I think, is that there are some language features that are a little misplaced in today's world. The biggest one is the fact that we have both types and interfaces. Those are two different ways in TypeScript to describe, I have an object or some shape, and I want to be able to later refer to that shape by some name. A lot of languages with types have interfaces. You know, C, Java, C, all of them have that or structs or some equivalent. And the fact that we have two of them in TypeScript and the community can never decide on which one to use, it's an act. It's almost tabs versus spaces level of debate. It's kind of inconvenient. There's a reason why this is the case. They kind of evolved organically. Types aliases is one of them. Kind of didn't start off super well. It wasn't originally in TypeScript, then got added more and more to the point where they can do most of what interfaces can do. But if we could just reset, go back 10 years and recreate it again, we'd probably have a little more clear delineation or even merging of the two concepts. Something that's a little more thought out from the beginning.
- [08:43]
Pavel Borkowski
Now. I was just wondering what was the actual. At the end of the day, because I use sometimes interfaces, for example, I define props for a React component and I usually use an interface for that. But like, I never actually thought, hey, how about I'm going to use a type? Because I just, you know, I just. Muscle memory. Just continue coding it out.
- [08:58]
Josh Goldberg
Yeah, so you can use an interface. The Way you do. Honestly, the way I do. That's my preference for a shape, you know, interface, fruit, name, string, value, number, whatever. Or you could use a typealias. Type fruit equals, you know, object, curlies, name, string, value, number. Most of the time the two are equivalent. There are some edge cases where you have to use an interface or you have to use a type. Typealiases can have unions, which are things saying this can be one of several possible types. This can be string or number, which is a feature not a lot of programming languages have in their type system. And then interfaces can merge together. Like if you have the global window interface and you say, hey, I added some global to the window, now all Windows should have it. You can do that with interfaces. So it really is muscle memory. Like in TypeScript Eslint, one of the projects I work on that helps standardize stylistic and conventions for TypeScript in the community. We just say, look, pick one and go with it. The most important thing is just being consistent with yourself.
- [09:53]
Pavel Borkowski
I think apart from that, there were also the name conventions I stumbled upon. I think on GitHub was this discussion a while ago. Should you start the interfaces with I? For example, like you have I component and then you just call it with I. Personally, this is also my muscle memory. So whenever I leave an I in front of an interface, wherever in the code base, you kind of know that this is me. But then other people weren't using this. I was wondering, like, does it really make sense? Right? Because for me, for example, it was easier to. And to follow this convention instead of to kind of make it easier to read. But for myself, maybe not.
- [10:22]
Josh Goldberg
There are very old code conventions that are kind of still in the community here. One of those is the idea of prefixing names with what those things are. I can never remember. There's this whole deep dive. I also that folks, on my Hungarian notation there it is. Hungarian.
- [10:39]
Pavel Borkowski
Hungarian, yeah.
- [10:40]
Josh Goldberg
A lot of those notations started out of one of two possible concerns. One is that I want to be able to describe the type of this thing. But I'm working in a language where it's actually really inconvenient to find the type. No, you know, go to reference or go to definition the way we have it, TypeScript. So you'd put like T something or I something to say it's like a template or an interface. That is not super useful these days in TypeScript because we have such great tooling. Same with C and Java and Kotlin and Swift. So for the most part, the recommendation is don't start your interfaces with I always it's redundant, it's unnecessary. There are better ways of knowing what's an interface. But you know, some people still do it.
- [11:14]
Pavel Borkowski
So yeah, I still do. But like I learned it kind of at work from other people that kind of introduced me to TypeScript in the beginning and I just kept on doing this. But occasionally like you don't question it, you know, after a while, keep that convention. And I was wondering, do you have any tips for Typescript developers, people that use Typescript, how to be most productive with the language, what things to avoid, what things maybe to focus on more?
- [11:36]
Josh Goldberg
Yeah, I'd say to start if at all possible, treat it as something you should learn. I know not everyone has time for everything and this is yet another random technical thing people are suggesting one could learn. But it's really useful to understand the tools you're using. So read the Typescript docs Honestly, the release notes on new versions do a fantastic job of explaining new features in TypeScript and then link to the appropriate resources. If you know Typescript well, it becomes a much more pleasant process to write it. That's my number one tip. My number two tip is of course use a Linter DSLINT or Biome or typescript eslint, whatever it is something that can enforce good best practices and consistent styling that'll help you get the most out of your language and catch a lot of bugs for you.
- [12:17]
Pavel Borkowski
I think this provides a nice segue into slint because in general linting the process of linting in slint what it is, why do we need it? Why for example I need this in JavaScript versus I might not need a linter thing in Swift or not any other strongly typed languages.
- [12:34]
Josh Goldberg
There are three really common static analysis tools, tools that run on your code but don't actually build and then run your code. Static analysis as opposed to dynamic like testing, formatting, linting, type checking. Formatters like prettier are very dumb in a good way. They just reformat your code. That's conceptually the simplest, although fun fact, very difficult to implement. Linters and Type checkers are two different things. Type checkers like TypeScript just look out correctness. They provide a set of APIs that other tools can use to learn about your code, about the types and they'll tell you if you have a type mismatch like an assignability issue. This is supposed to be boolean you assigned, I don't know, string array, whatever, but they don't check for stylistic consistency, they don't check for likely bugs they don't check for hey, my team said that we should move from that deprecated function to this new function, but you're still calling the old deprecated one. There are a whole plethora of things you can do with linters that just are not a good fit, just do not make sense in type checking. So that's why I definitely recommend if you're using TypeScript, if it's justified at your scale of project to use TypeScript, it's almost certainly also justified to use something like ESLint to lint your code.
- [13:44]
Pavel Borkowski
And you are an open source developer wizard at TypeScript ESLint, which is very popular, and I was wondering what is your role in the development? How did you get into this position? How did you start with being the open source developer on this project? And why is it separate, for example, from the ESLint itself?
- [14:04]
Josh Goldberg
We get a lot of questions. When is ESLint going to build in TypeScript support first class it's a very interesting debate. So ESLint is the standard JavaScript linter. Fun fact. It does not actually stand for ECMAScript lint. Nowhere in the documentation does it specifically say that. So we've been trying to find extra fun things to call it like extra spicy linter, but it's basically the ECMAScript linter. It's just for JavaScript ECMAScript. That's all it does. It does a great job of that. It sets up a nice base that plugins another ecosystem community projects can build on, but it doesn't support random ad hoc extensions to JavaScript such as TypeScript or Flow or CoffeeScript or AS. No, or anything. That's a philosophical standpoint that the technical steering committee of eoslint currently has had for the last decade plus and will probably have for a while. So then it comes to the community to build in. Let's say you want a parser that takes in TypeScript syntax and converts it to a format Eslint can use. Or if you want to have an Eslint plugin which contains a whole set of rules specific to, let's say, TypeScript code. So that parser and the Eslint plugin are the main things that TypeScript Eslint provides. So you're using Eslint and then you add on TypeScript Eslint to additionally be able to support TypeScript the same way you might add on some other community plugin to support like JSON Linting or Markdown or YAML.
- [15:21]
Pavel Borkowski
I was just wondering what Would it? Because you say that in this case, what I understand that the typescript slint is more of a plugin to S Lint, right? So you kind of add it on top of it. It's not like a standalone for how much overlap you have in terms of because. And maybe speak a little bit about the linting rules, because a linter will operate, there will be a list of linting rules. For example, don't do this, don't do that, remove this part, and so on. So I was wondering who decides what those rules are and how do those new rules come into play and how do they become outdated?
- [15:50]
Josh Goldberg
Oh yeah, there are two kind of tiers of rules other than deprecated or old. We don't like this anymore. Rules that a Linter or a Linter plugin might have. The base level is these are the rules, provided we're not saying how you should use them. We might give you default options, but they're just available. Both eslint, which has its own team, I'm on one of the ESLint teams, the committer team, and then also TypeScript ESLint. I'm one of the three maintainers, along with our committers. We each provide a bunch of rules. Then also eslint and typescreet eslint provide what's called a shareable config or preset config, which says within those rules, these are the ones we recommend under a name like, let's say Recommended or for typescript, pslint, Strict or Stylistic. All of those shared configs, the ones that we actually recommend people use, those were informed by years and years of people trying out linters, finding which rules they like or don't like screaming at us on the Internet, Us or them. Back in the day of hey, we really hate that you put this in Recommended, stop doing that, that doesn't work for us. Or hey, this should be Recommended. So in theory, or ostensibly, the project itself, like the ESLint project, determines what's in recommended or TypeScript ESLint determines what's in its Recommended or Stylistic rule sets. But really both projects try to keep that very open with the community. It's an open dialogue. If you want to change something, you can file a GitHub issue or a discussion or post on Discord. So they are supposed to, and I think, for the most part, really do reflect what's actually currently community accepted. Best practice for JavaScript in eslint or JavaScript plus typescript in typescript eslint. If I'm wrong About that, if those are rules someone doesn't like, please yell at us on the Internet so we can make it better for you.
- [17:29]
Pavel Borkowski
And so the rules, as I understand it, they just came through years and years of the flame of Internet arguments.
- [17:35]
Josh Goldberg
Yes. Through that crucible was forged the typescript.
- [17:38]
Pavel Borkowski
Be a slint, types could be a SLINT emerged. So at the end of the day there'll be like one of three of you deciding, is this going in or not. Right. As maintainers, if somebody has a suggestion, suggestion or just a big discussion, we go by consensus.
- [17:50]
Josh Goldberg
There are three maintainers, three or four committer team members. If one of us really hates something and everyone else loves it, we'll still try to hash it out, figure out. Part of being an open source contributor maintainer committer is being able to work with people who you have very little actual shared context with. I don't think I've met any of the other TypeScript, ESLINT or ESLINT committers and maintainers in real life. So we just talk about it on the Internet and try to solicit input when possible. I really want to emphasize that it is a consensus driven process. It's not one person said and then thus it shall be said.
- [18:22]
Pavel Borkowski
Yeah, I was just wondering because also specifically within the world of JavaScript, I always compare JavaScript and all the frameworks around this zoo that you go in and there is a lot of animals and each single one is of different shape. And every person that works in the zoo does things in a different way because you can move within. As a JavaScript developer from Project to project, I spent a lot of time in the beginning of a project picking up new frameworks, learning. For example, if you switch from Angular to React, the concepts will be different. We went through so many state management libraries from MobX to Redux and so on. And as soon as you switch the project, it's almost like a stressful moment because those new animals jumping at you. So you're just wondering the person who decides, apart from obviously this metaphor, who will decide? Okay, this is the way we're going to write TypeScript. If you're using the TypeScript S Lens, what's more, looking Is there something.
- [19:11]
Josh Goldberg
Yeah. In the projects themselves, like the core projects like Eslint for TypeScript, we try to just focus on things that are universal to everyone. We wouldn't encode, I don't know, like Angular or React specific stuff. I personally have a very soft sweet happy spot in my heart for MobX. Love that library. I miss the days of working with it. But that's love mobx. Love that you brought it up. Great library.
- [19:34]
Pavel Borkowski
I'm having a really good time as well.
- [19:39]
Josh Goldberg
I love it. What a great library.
- [19:40]
Pavel Borkowski
The Mobix. It is great, but in the beginning it was pain, but then it like. Like the first week I think, because I, when I was learning I got jumped on this project and it's like you have to do it in a week with a new library that you never used in your life. So like you had to learn really fast. But then once I've seen how people used it in the wild, they've organized the code really nicely. I recommend this now for any new project that I take on.
- [20:02]
Josh Goldberg
That's great. If only there was some tool that could automatically run in your editor and give you best practices and other, you know, conventional feedback as you learn a new tool. That's one of the downsides and the positives of Eslint that every project typically has. Like every popular mainstream JavaScript project typically has an Eslint plugin. Like there's an Eslint plugin for next JS. There are actually two for React, one from the React team and one from the community around. More stuff. There's also a general JSX plugin, bajillion plugins, plugins everywhere. So on the bright side, if you use something new and popular, like if you switch from, I don't know, React to solid js, there will be an eslint plugin you can use that'll help you with that. And that plugin will have been informed hopefully and I believe generally by the community, by people collaborating the same way as we do on instead of the general typescript stuff, the specific whatever React or solid JS stuff or it'll be from the team itself and they tend to know best how to do the thing they built. The downside then is yeah, you have to configure some new plugin and some of them aren't just, you know, put one line in and it works. Some of them have a little configuration. So that's one of the bigger ecosystem pains we have in eslint. Just getting that dang config file to work with. Your specific unique, glorious JavaScript situation for.
- [21:11]
Pavel Borkowski
Me usually was as soon as I set it, I just want to forget it. I want this to work and focus on the project, right? It's safe just to keep the eslint from saving me or any other developers from pushing something that would be obviously wrong and just keep it within the CI CD pipeline and kind of block the commits that you know, for example, would be not adhering to the rules that we have selected or have been selected for us.
- [21:33]
Josh Goldberg
At the same time, as much as I love dev tooling and putting hours upon hours of work a week or even day into this stuff, we should recognize that most developers don't want to care about this. They really don't want to care about semantically, should this rule be in the strict recommended preset. They just, as you said, just put the dang config there and Let Me Be Productive One of our biggest tasks as open source maintainers is to try to let people be productive with as little work as possible on their ends.
- [21:59]
Height
To work with us Introducing Height, the only autonomous project management tool, backlog grooming, bug triage, keeping documentation up to date. Those aren't why you got into product building, right? Well, height handles all that grunt work for you. Using a first of its kind AI approach, Height proactively takes care of time consuming workflows without you lifting a fingerprint. Height recognizes when you've agreed to trim, scope and handles, mapping the necessary edits back to your product brief. When new tickets are added to your backlog, Height comes through them, adding feature tags, time estimates and more. And it's not just you. Everyone on your team manages projects, tracking updates, scoping work, balancing priorities. But whether or not your product succeeds shouldn't depend on project management. With height, autonomous workflows handle that mundane upkeep so your team can focus on building great products. If you're ready to stop managing projects, it's time for height join the new era of product building where projects manage themselves. Visit Height app Sedaily to get started.
- [22:56]
Pavel Borkowski
So recently you have released a new version of TypeScript. ESLint is the version 8 are you in the process of releasing currently? So I was wondering what's the current stage of it and what are the biggest changes and improvements that you are putting in?
- [23:09]
Josh Goldberg
Oh yeah, there are two big headliner features for this release specifically. One is that we finally support ESLINT v9. I have found it to be a pain point in the community. Both that we don't have the same version number as Eslint, we're one behind. And also that the latest Eslint version V9 came out beginning of 2024 is not actually technically supported by Typeshift Eslint V7, our previous current major so there are some breaking changes, some internal shenanigans we had to do, but TypeScript VSLN V8 actually supports the S Lint V9. Boom. Hooray. No more peer dependency warnings. The second thing is that we have a new way to do what's called typed linting. It's one of the big value props of Type should be a slint that in addition to supporting TypeScript syntax and giving you rules around that syntax, we also can actually use the TypeScript Type Checker, the APIs from TypeScript Type Checker, to make a significantly more powerful class of lint rules called Type lint rules. The upside of that is, oh my gosh, they're so freaking powerful. Like, we can detect bugs from asynchronous code execution by detecting what's a promise? Did you make a promise? Did you handle it correctly? Something no other linter can do with JavaScript land reliably. But then the downside is it's actually kind of a pain again to configure it because you're merging together two tools, Eslint and TypeScript, that aren't architected with the same goals. So we have this new thing called the project service in TypeScript VSLINT v8 that is faster than the old ways of doing things should ideally and in my experience generally does make a much more straightforward streamlined configuration experience and works more similarly to how TypeScript works in editors like VS Code. So you're having generally more reliability in your type linting. Fewer weird discrepancies between TypeScript and eSlint.
- [24:48]
Pavel Borkowski
So how does the project service work? Can you speak a little bit more about it?
- [24:53]
Josh Goldberg
Sure. There are two ways of setting up typed linting in TypeScript BSLint. The old way is called Project parseroptions project. The new way is Project service. In the old way we would use manual TypeScript APIs where we would be told by you which TypeScript projects or tsconfig files your TypeScript configuration files to use. We can auto detect them the closest for each file with Project true or like taking a string array. When you start linting, we create what's called a TypeScript program, which is like the representation of your TypeScript going on programmatically for each project. And then whenever you want to lint a file we'll ask TypeScript APIs, hey, given this file path, the corresponding TypeScript program, give me the type information for that file. The problem with using manual typescript APIs is we mess it up. Sometimes people give us the wrong projects or there are weird TypeScript features that aren't quite supported in our tooling yet. Like Project references is the name of a feature our old project tooling didn't support. So what we do now instead with Project service, which you don't have to use one or the other, you can use one or the other up to you. But we recommend Project service now is we call a much more. I think the term is black box. Like just use whatever seems right to you. TypeScript API actually the same one that editors like VS code use. So what we'll say is, hey, this is the default settings for TypeScript if you need them. This is the project service thing. Go find me the type information for this file. And because we are calling to the same APIs as an editor, you use the same logic as an editor to determine the settings for each file. So we support project references out of the box and it's a lot more optimized because this is what VS code uses and other editors like this needs to be fast. So we've seen performance improvements of 10 to 20% out of the box. We've seen people go from 20 lines of config up to in their eslink config down to 1 to 10, 1 to 5. Most commonly it's been a win around the box. There are random edge case bugs that are why We've waited until V8 to make this thing marked as stable and usable. But we're really excited about it. I think it makes things a lot.
- [26:52]
Pavel Borkowski
Nicer for folks, especially from the performance perspective for large projects that are already there, they need. If you have this say within Visual Studio code and you change one thing and then Esalen starts, for example, updating it might take, well, oh my gosh. So occasionally I even had this switched off for a while on larger projects just to run faster and then do it right after. So I was wondering when you said that you getting the type information from a file. So imagine that I have for example next js root with some handler or some front end file. What do you mean that you get the types from the file? Do you extract basically all the entities and the types that were there, all the interfaces or all of the types that were imported?
- [27:31]
Josh Goldberg
I love this question. Let's talk about how TypeScript works, about how static analysis works. People get scared when you say phrasing like that, but it's actually, I think very surface level. We're not going to dive too deep. The way tools like Eslint and TypeScript represent or reason about your code is with what's called an abstract syntax tree or ast. It's a big object that describes all the stuff in your file. It's called a Tree because you have things with children, you might have like a variable statement where the children are the name and then the initial value and then also the kind, if it's like var or let or whatnot. The way ESLint rules work, each thing you might want to enforce with eslint is enforced by one rule is the rule takes in your ast, the big object describing your file, and it looks for little patterns in the file. Like if you have a variable declaration where the kind is var, the hey, you should use let rule will kick in and say, ah, you should use let. TypeScript also represents things within AST. It's a different format than ESLint, but it's the same idea. So when you have an Eslint rule that runs through the TypeScript Eslint's tooling, what you can do is you can ask our APIs to ask TypeScript APIs, given this node, this thing in the AST, what does TypeScript think the type is like? If you give it the name of a variable and that variable is initialized to a string, TypeScript will tell you, ah, we've inferred it to be type string. Thus your eslin rules can use that type information alongside their normal AST checking logic. Does that answer what you were looking for?
- [28:56]
Pavel Borkowski
Yeah. So then you extract all of them. And then when you would apply the s lint rules on that on top of it, right? So for example, you would have the AST tree of the file itself. You would ask TypeScript, for example, what the types are with the slend. Because I never looked through the SLEND rules at the code. So I'm just wondering what do they actually do? Do they run through the entire tree and just try to analyze? Because you said that some of them might be checking if it's a var and it should be a let. So this seems like a more simple one that you have arrived at a certain node where you figure out, okay, the var should be let. That's it, right? But given that this is a tree, I think that some of them might be getting much more complicated than this. Is that correct?
- [29:34]
Josh Goldberg
Oh, yeah. Most of them honestly are relatively straightforward, but some of them are just ridiculous. Some of them I shudder to work on. We've built up a set of utilities Eslint has. We haven't TypeScript Eslint that make it easier to work with this stuff. For example, let's talk about unused variable detection. TypeScript actually has a couple of compiler options. No unused locals, no unused parameters that can have TypeScript error on something being unused. That's like the most linter area thing Typescript does. They've talked about adding more, but decided, no, let's let the linters do that, because people actually really want to configure this stuff. If you want your lint rule, no one used vars to detect this stuff. Well, each lint rule works on one file at a time. It takes one file's ast with some metadata about the file and is supposed to call some function whenever it sees a complaint. How do you know if a variable is unused? Well, what if the variables name is known like let name equals Josh. You can check for any identifier, it's called a name. And if there's only one identifier in the variable declaration, then you know it's unused. But what if you have a bunch of variables named name or whatever equivalent in a bunch of different functions? How do you know that function? You know, log Josh has a let name and log Powell has a name, and those two names are different. So then you have to do what's called scope analysis, which is where you build up a big description of for each variable, for each identifier. Here's where it was declared and then you get the concept of, you know, scoped identifiers. And then you can check is this scoped identifier used anywhere else? So that's not even using type information. That's just one of the more complex lint rules that one might want to run on code.
- [31:08]
Pavel Borkowski
Would that also work, for example, if you are exporting a variable, right? So you kind of say it's unused within the file, but then you're exporting it to another file. It wouldn't pass this check. Or it would.
- [31:18]
Josh Goldberg
It would pass the check because in export, hey, that's using the thing, which actually is one of the really key structural limitations of eslint and kind of a typescript that they both generally work on a per file or per whether this is used at all basis. If you export a variable that's never used anywhere else, eslint has no way of checking for this. We've tried to build this rule in eslint, but structurally it's just hard because lint rules are designed to work on one file at a time. So I actually recommend people to go use another tool for that, something called knip. Knip, it's Dutch for cut, that does this kind of cross file analysis for unused code or dependencies. Great tool. Highly recommend that makes sense because it's.
- [31:57]
Pavel Borkowski
Much easier from the perspective of eslin to find an unused import than to find an unused export. Because the import you can see, okay, you import this and you're just not using this within the file.
- [32:06]
Josh Goldberg
Exactly. That's interesting.
- [32:08]
Pavel Borkowski
And it's still like if you have large code base and a lot of those tasks I would imagine are recursive or just running through the tree there and back trying to check obviously with a lot of optimizations. And there is no wonder why occasionally that this will get slow.
- [32:22]
Josh Goldberg
Yeah, we've found is that in addition to complex config files, performance of type checked linting of cross file linting is one of the big top three pains in the eslint ecosystem. That's why there are alternative linters like Biome Ox Lint Denolint that are getting popular because although they don't have type linting yet, they are shockingly fast, orders of magnitude faster. And people love that. So we're working on performance in TypeScript BSLint ESLint is going through an early stage of a rewrite which will hopefully structurally help with that too. But fundamentally, yeah, if you're linting with a lot of files at once and or with slow stuff like full TypeScript type checking performance is one of the trade offs you have to work with.
- [33:06]
Pavel Borkowski
Yeah. Because you're not only as you mentioned earlier, but to reiterate on that, you're not only on the TypeScript Essend team, you are also on the ESLint team now being the bridge between the two.
- [33:15]
Josh Goldberg
Something like that. Yeah.
- [33:17]
Pavel Borkowski
Because when I was wondering, like for example, as you said that for example Type that they're one version ahead, you're one version behind, then you have to work with TypeScript and it seems that there's always somebody chasing somebody. So in this case Esalen being, you know, the kind of. And the leading package and you more conforming to whatever they change and not vice versa. So maybe you being the bridge in both is going to make it more equal.
- [33:39]
Josh Goldberg
I hope to do that. I hope to take on more of a role of that as time goes on. It's hard because for starters, I just joined EOS LINT this year in 2024, early January. I'm also not on the technical steering committee, what they refer to as what we refer to as maintainers. I'm just a committer. So I'm not, you know, I'm not the most influential person in the room. I'm new to this, I'm still learning, I'm still ramping up. Also, open source projects are not corporate Funded teams. We're not typescript, we don't have the backing of Microsoft. We're a true independent project, both of us are. So we are very limited resourcing and budgeting for even the bare necessities of triage and GitHub issues, let alone planning for the future and collaborating with ecosystem partners. When you're a project like Eslint that touches basically every JavaScript project in production, or at least a super majority of them, it's really hard to find the time to do the due diligence that one would ideally want to do when say, working with partners or releasing new versions.
- [34:37]
Pavel Borkowski
And so you work on open source full time now and in the past you have worked at Microsoft, you have worked at Codecademy. So how is the life of an open source developer and how is it different than your life when you were an employee?
- [34:50]
Josh Goldberg
First of all, I appreciate you pronouncing Codecademy correctly. There's no A in the middle. That gets a lot of people. Yeah, you got it right.
- [34:56]
Pavel Borkowski
Most people have a Slavic accent, you know, and coming into that, just pronouncing a single word that's written in single letter.
- [35:03]
Josh Goldberg
Yeah. As someone who works on Linters a lot of the time, I appreciate the precision and accuracy. The way that I try to introduce the concept of working open source to people is imagine as a company gets bigger, you know, fewer and fewer people around you, you get more and more separated. Like you're working at like Codecademy was when I was there, let's say like 200 people scale, you know everyone there, you know all the developers. You might not work closely, closely with all them, but you know them. Then you get to like a mid sized company where you know of most of the teams maybe, but you don't work with a lot of them. And then you get to like Microsoft or Amazon, where there are internal politics, where entire organizations get shafted because someone had a bad year or something, then go even further beyond that. That's what open source is like. No one knows anyone. There's no core organization, there's no goal. Thank God we don't have stockholders to appease because we have no money. Haha. But it's just, you're out on the open, there's no structure, you got to do everything yourself. And if you're lucky, you'll find a few people you can consistently work with who you also enjoy working with.
- [36:07]
Pavel Borkowski
It sounds more like being a founder of a bootstrap startup than working at a large because then it's still you kind of alone in this world, in this universe of other products and requests.
- [36:19]
Josh Goldberg
The loneliness of a founder with the backing money of a charity.
- [36:22]
Pavel Borkowski
And what is the best part?
- [36:25]
Josh Goldberg
The best part is that I get to work on the stuff everyone uses. Like whenever I, let's say, merge a feature in TypeScript eSlint, something I'm excited about, that means everyone who is linting typescript with eslint gets to benefit from that feature. If I fix a real pain in the butt with, you know, documentation or onboarding or something that's making it better for whatever number of thousands people, people I really like that. I think it's very satisfying. Like I truly deeply satisfied and happy with my work in a way that I, you know, rarely got to be with corporate work, not appeasing the stockholders or one specific segment of people. I'm, you know, working for everyone who's a dev. And then it's also really good for me professionally. I've made a bajillion connections in industry and other open source spaces. I've gotten to speak at conferences because I have a really flexible schedule and work on tooling that everyone should care about in the typescript world. So if and when I go back into corporate life, if I want to start a family and have a real paycheck and health insurance, then I will have been benefited by doing this.
- [37:24]
Pavel Borkowski
And what is the most challenging part of maintaining open source projects? Because obviously you meet all those great people, but then would you have issues with managing their requests? Any expectations that those people that use this and the user work that they have?
- [37:41]
Josh Goldberg
Yeah, I think the general umbrella is that the industry as a whole doesn't really understand open source. It's getting slowly better at it. Some people, even some companies do understand it pretty well or very deeply. But we get a lot of people who send us a screenshot of their EOS lint error and no other context and they won't even put alt text on the screenshot, which is an accessibility. No, no. What if I was blind? Would I be able to help you? And then they get mad when we ask them for, hey, I have no idea what the hell you're asking me for. Can you provide any context such as what was asked for in the contributing guide that you marked as having read as part of the issue checkbox? That's very frustrating. It's off put or offset by the positivity that a lot of people do respect and appreciate open source and the maintainers behind it, which makes me feel good. But it can be Very isolating to have to deal with hordes of crap and then not having a manager or dedicated company mentor or team around me to just be kind of floating off in the deep end for years and.
- [38:39]
Pavel Borkowski
Having to deal with it indirectly because at the same time it's an important work, right? Because you're building the fundamentals of a lot of modern web applications and of JavaScript, especially if you work within stuff like S Land or typescript Land or any other open source library that's used quite widely. And then you have people who come and they, they got it for free. Yet by providing a description not detailed enough will actually steer you away from pushing more crystallized thoughts into this code base which then later will be propagated to a lot of millions of projects. And you're just there with the screenshot trying to figure out what that person who is angry is trying to say.
- [39:18]
Josh Goldberg
And the fun part of that, fun with quotes, is that every angry person contains a deeply satisfied user or at least the potential for that on the inside. You know, if I respond curtly to someone who just posts a screenshot angrily or similar bad behavior, I'm well within my rights. We have a contributing guide. There are enough resources, you should know how to do this. GitHub even has things. But if I respond kindly, if I link to the specific part of the contributing guide they say they read, you can tell I'm bitter about this. Then oftentimes that converts them into someone who's first apologetic for being rude and then actually a proponent of the library and control contributor. So depending on how much emotional energy I have on a week, I might put more effort into these kinds of user reports.
- [40:01]
Pavel Borkowski
Doing marketing through customer like developer service almost.
- [40:05]
Josh Goldberg
Yeah, GitHub issues is a marketing funnel.
- [40:07]
Pavel Borkowski
Yeah, yeah, I used one library that I don't want to name, but the very useful, excellent code. The maintainers, very, very good developers. However, asking for anything on their internal forums. It's just, it's scary because this main maintainer who's an excellent engineer, whether he would just say yeah, just go and.
- [40:27]
Josh Goldberg
Just go search in Google rtfm. Read the effing manual pretty much and.
- [40:33]
Pavel Borkowski
In a very kind of angry phrasing. So I never asked anything. I just found a lot of other people that asked and they were just like put down a lot.
- [40:41]
Josh Goldberg
That's not a good open source maintainer.
- [40:43]
Pavel Borkowski
No, but however the library is actually Exxon, so and I use it widely also, as you said that if something goes wrong, as a founder of a small and a video conferencing business. Also, I knew that I won't get praise every day, oh, this is great. But as soon as something breaks and I start getting emails, excuse me, this doesn't work. I'm like, okay, this is actually useful what I made.
- [41:04]
Josh Goldberg
Right.
- [41:05]
Pavel Borkowski
And so at least you have this and this negative feedback actually being a positive feedback in this case.
- [41:10]
Josh Goldberg
Yeah.
- [41:11]
Pavel Borkowski
And I was wondering, how do you resolve any conflicts and arguments within open source projects?
- [41:16]
Josh Goldberg
It's tough. You don't have a remediation team or HR to fall back on. Fortunately, open source kind of selects for people who are there for the sake of being there. You get a lot of people who do first contributions because they want to bolster their LinkedIn, get that first job, build a name. But people who are consistently there are for the most part pretty passionate about it. So that passion comes with some fiery emotions sometimes. But it's hard to be an open source maintainer with other people long term if you don't have the ability to put your passions aside, your personal context aside, and try to deeply understand what other people are doing. So I highly recommend anyone who's a developer and has the time to read books on this stuff. Read I Got three Books in Order for y'all. How to Win Friends and Influence People. Updated for the 21st century. The original version, I've Learned the Hard Way, is not a great book to recommend to people this day and age. Radical candor and nonviolent communication. Those three books are a huge foundation of how I approach problem solving and consensus gathering online. The general gist is you can't argue with someone, you can't even debate them. You shouldn't argue, you should discuss until you truly understand what they're trying to say. So until what they're trying to get to and the reasons behind it is publicly in a GitHub issue, or if you're having a private discussion in the chat, there's no point to try to throw your opinion at them because what do they care about your opinion? You don't even know what they're trying to say. And I found that 99% of the time if we're having a disagreement on a rule, us figuring out what each other is actually looking for and what the reasons behind that are, that will turn that discussion into something productive rather than a heated debate.
- [42:55]
Pavel Borkowski
I think this is very wise and I'm definitely going to have a look at the books as well. I was wondering, apart from recommending those three books for any future developers who might get into open source, but I think this is useful more in general life than only open source. What other advice would you give for any developers that maybe for boosting their LinkedIn profile even or out of passion that they want to get into open source and contribute?
- [43:20]
Josh Goldberg
I'd say there are no bad reasons or very few bad reasons to contribute to open source. If you're just in it for the money, whether that's development or open source, well, hopefully you're just in development for the money. Open source doesn't have a lot for most projects. Great, fine, that's totally valid. You know, we live in a capitalist world. Sometimes you gotta do what you gotta do. Actually, oftentimes I'd say I slowly ramped into open source. I did not just learn to code and then boom, I'm a maintainer. I got a quote unquote real job. I had internships first and corporate jobs and those taught me a lot of really good skills. How to work with people, how to code, how to learn a new tool, framework, architecture, language. Building up those skills first is immensely useful. So if you have a job and you're thinking of quitting and going open source, it's a risk. Make sure you have money first, but also make sure you've gotten what you want and need out of the job. If you don't have a job and you want to get a job and to use open source as a way, great. Open source can be a fantastic way to bolster your LinkedIn, your GitHub, to learn new skills. Because open source source projects can oftentimes be using different tech than what you're used to. I'd say to try to deeply understand as much as you have time to whatever it is you're working on. Don't just go to a project and I don't know, throw some code there on the pull request and then see what happens. Actually read the project's documentation, see previous pull requests. How do people approach writing tests in this project? It'll save you and the maintainer a lot of time. If you do your due diligence and read a lot and try, try to do a good job and understand what you're working on and then ask questions, informed questions, whenever there's a gap, that really helps.
- [44:58]
Pavel Borkowski
So I think what you mentioned with not just making like a random feature request with some code that you think without understanding everything. I think that occasionally you have developers who are great developers, but a developer on a project who understands the code base very well might be very valuable. Even more than somebody who's very smart can come you know, and quickly fix something or try to push some smart feature without understanding the entire concept. Even if it's not done well, the project, if it's not organized well, there's still some knowledge that developers need to have in order to navigate quickly through it and to also have the intuition on. For example, if I push this feature, is this going to break something else? Is this going to be out of the conventions that we have decided to use? Or for example, is it not becoming a Frankenstein project versus something that's coherent and unified?
- [45:50]
Josh Goldberg
That's important.
- [45:51]
Pavel Borkowski
I wanted to come back a little bit to this is my own personal question out of curiosity, because you have published the Learning typescript book and I was wondering what's the process of releasing a book about programming? What was your work process? How long did it take you and are you still updating it? What's the story behind it?
- [46:08]
Josh Goldberg
Yeah, still updating it. Whenever someone posts errata, which is the O'Reilly and Common Book term for typo, or this is unclear, I'll update, which then can go into electronic version. Unfortunately not the print version, although I would love to in a couple years maybe look at a second.
- [46:24]
Pavel Borkowski
It's like a pr, basically. It's like a bug repo.
- [46:26]
Josh Goldberg
Yeah, it's actually a git repo, a git repository on the inside. So I send commits in. It's not GitHub. It's like an internal thing. But yeah, similar to how one might scaffold out a new project architecture or a course online. You start with the very broad stuff and then get more granular over time. When I first started working on the book, it was O'Reilly who reached out to me because at the time I was already kind of known in open source and with my blog and giving wacky talks at typescript conferences. So they wanted a book. The very broad Sense to teach TypeScript, like the new learning TypeScript give or take book. They wanted that because there was an opening in the market. They hadn't released one in recent years. TypeScript, as any programming language, evolves every few years over the years. So I was well positioned at the time I was working at codecademy to take the teachings from being on a dev team and helping codecademy with a few courses to write a book. So that was stage one. What is the book? Stage two was like, you know, what are the inputs and outputs? We decided the input would be. You need to know JavaScript somewhat. You don't need to be an expert. But like, it's really hard to teach TypeScript, a superset of JavaScript. If you don't actually know JavaScript, that's a much larger book and the output should be. You don't need to be an expert on TypeScript to use it, but you should know how it works. Like what are the philosophies, how does a type system fundamentally work? And then like, you know, a lot of the important and some of the useful, but maybe not as common features. So that was stage two. Stage three out of four was setting up what are the chapters. You know, should arrays come before objects and or functions. Like when do you teach conditional types? Do you even teach conditional types well, and so on. So we kind of set up what computer scientists would call a DAG directed acyclic graph, what teachers would call a learning flow. By the way, DAG is a concept oh, so useful for teaching. And then stage four was it took about most of that year. Go through each of those chapters in order and write them. It's like writing a lot of long blog posts over the course of a year with the added benefit of having a very useful editor and O'Reilly team to support me in that.
- [48:27]
Pavel Borkowski
It's amazing. And so it's becoming I think slowly the go to for learning job. Sorry.
- [48:33]
Josh Goldberg
In Typescript at the same time, it's one of them. The Typescript documentation. The Typescript handbook is fantastic. Free, open source, it's a starter, it doesn't go deep. It not as well structured as like a book or online course would be because it's a handbook. The nature of books and programming is that as soon as you think you're on top, someone else comes along. Matt Pocock, who is a very well known and very, very good Typescript educator, is I think he just recently released the free total Typescript book which is another format I recommend. Not every format is for everyone. I personally can't stand learning on videos or through lectures, so books for me. But other people might prefer his course or his videos. So I am currently the most popular print book for learning TypeScript that I know of. Or at least like the biggest mind share in the conferences I talk to, which is admittedly a very skewed and biased perspective.
- [49:23]
Pavel Borkowski
How did you select a pirate?
- [49:24]
Josh Goldberg
You know what? I didn't and I would have loved more say in that process. I was relieved. They don't tell you what it's going to be. They ask you, hey, we might not listen to you, but do you have any requests? I just wanted a parakeet because I grew up with a beautiful Green budgie named Emeralds. He was the cutest thing ever. So I was relieved that it was a pretty bird. But you know, there's a secret CABAL Deep within O'Reilly that even my editors didn't have access to that chose that.
- [49:51]
Pavel Borkowski
Because I was wondering, it's like they call you up and they ask, well, what's your favorite animal? It's like, I love boars. I think there was one book with a boar in the front.
- [49:58]
Josh Goldberg
Yeah, I mean, I feel bad for the rust people. Their stuff is all crabs.
- [50:02]
Pavel Borkowski
What did they get? I'll have to check it out.
- [50:05]
Josh Goldberg
Crabs. I'm never going to throw shade at another ecosystem, but you know, I'll throw shade at the rust crab. That's a weird mascot to have as a hook thing.
- [50:14]
Pavel Borkowski
Seafood oriented. I wonder how many people watch podcasts on the video versus on just audio. So for whoever is just listening, Josh is looking for the parrot.
- [50:25]
Josh Goldberg
I'll leave this as an exercise for the reader. The parrot's on the front cover, but there's an explanation somewhere in the book. I can never remember where of. Like actually the way the reason why O'Reilly does this is like every animal is like something important. Like ah, I found it. The animal on the COVID learning types of Sun Conure Aretinga Solstice. It gives a little explanation. A lot of the animals are like endangered or threatened. So it's a nice thing they do.
- [50:49]
Pavel Borkowski
Definitely nice. And actually I quite like the COVID And I was wondering, with all the experience and the detailed knowledge you know about BO, TypeScript and JavaScript that you have, where do you see evolving within, let's say five years? What are the biggest challenges within not just linting and TypeScript, but within the entire ecosystem that you think we are facing?
- [51:12]
Josh Goldberg
The JavaScript ecosystem is big and wide and deep enough that there are multiple areas of advancement. One that I don't personally think about a lot, although I recognize as very big and important, is like the top of the scale for UIs for react and solid and angular that these UI previously libraries, now really large frameworks and meta frameworks are getting more and more expansive and better and better at doing their job. Like if you look at React server components or the equivalents and other UI things, it's just so far ahead of what we were doing even five years ago, pre hooks even. But for specifically the areas I work in like JavaScript, TypeScript tooling, I think there's already a big push for performance, for rewriting things in faster and more memory safe languages like Rust So faster than JavaScript, more safe than C C. I think that the ecosystem tends to fluctuate between this tool can do everything but it's a pain to configure and this tool does everything with relatively fewer configuration options so it's harder to extend and we're moving towards the easier to configuration one tool like a biom or XC that does everything but then like their plugin models are not as first class as like an eslint. And another analogy would be like moving from webpack to vite. So it took a little while for vite to get as community embraced as pluggable as webpack, but it's so much nicer as you know by design. So I think that hopefully we get more competition in the Eslint linting ecosystem. I really don't like that TypeScript is but TypeCreeps is the only one that has typed rules. I'm happy to continue innovating here to push forward things like project service and our recommended stylistic and strict preset configs. We just merged earlier this summer a rule that enforces the golden rule of generics which I leave as an exercise for the listener or viewer to go find on our docs. No unnecessary type parameters. But you know it's always in flux and I look forward to seeing, you know, faster, easier to configure tools competing with us. That would deeply make me happy and personally for you.
- [53:18]
Pavel Borkowski
What are your long and short term goals now within the open source space and any fun cool projects that you kept in secret, maybe that you're about to reveal?
- [53:30]
Josh Goldberg
Nothing secret. I can't stand working on secret projects in part because I'm too braggadocious, in part because it costs more on hosting services to keep things private. For eslint. I'm still ramping up on the team, you know, like I really want to get deeply from familiar with it and then be able to help with the rewrites for eslint. Specifically I want to ramp up on it, you know, become a deeply committed member of the project and understand how it works and then help with the rewrite for types at ESLINT V8 stable get the project service stable. We have a backlog of issues suggesting like new rules and niceties. So I really think for us our excellence is providing you the best set of rules linting typescript lint rules imaginable. Like for example the no unnecessary type parameters one to really really be able to enforce and push forward best practices in the typescript world. Other linters will have to follow suit. And once they have feature parity with us and have different architectures, they'll be able to innovate too. And honestly, they already are in ways that we haven't thought of or don't have a good positioning to, which is, I think, really good for the ecosystem system long term. For me, I put a blog post on this beginning of each year with my intent and then at the end of the year how that intent went, which you know is never as intended. I want to do those things. I want to continue to push forward my TypeScript template. I have a little thing called create TypeScript app that can create a new really, really nicely configured TypeScript just like a little CLI or node application with all the bells and whistles for tooling that one could want. Type typescript and knip and all this stuff. And I want to turn that into like kind of a generalized creator template so that someone who's making like a Create Next app or Create React app or Create types depth could build on this shared foundation. I actually co own the Create package on NPM now. Thanks Nate from Vercel for letting me be on that. And then I also want to make a linter for GitHub issues and pull requests and discussions. Like I have 15 different actions I use to like oh, is your issue adhering to the format? Is your pull request addressing an issue that's marked as whatever label you want accepting pull requests? And it's just such a pain to set those up individually.
- [55:39]
Pavel Borkowski
Would you see the open source and the PR linter to work mostly for open source projects for open projects? Or would you see this working within companies as well?
- [55:49]
Josh Goldberg
I prioritize open source selfishly and theologically, but I see no reason why I would restrict it from companies. I mean architecturally it's a lot harder and a lot more different to Write like a GitHub pull request action bot verifier, especially if you want to start applying auto fixes, then GitHub pull request permissions come into play and you might need a hosting service or you know, serverless app or something. So maybe a profit model would be to charge companies or just charge private repos for this. I don't know. I haven't even started working on this. It's months down the line. I'll be lucky if I start working on it in the fall at this.
- [56:23]
Pavel Borkowski
Point and just find the most pedantic CTOs of any companies and just preach it to them to make sure that all the PRs that their developers push. Oh yeah, screenshot, description, everything, video.
- [56:36]
Josh Goldberg
I've seen some pedantic ctos. I don't encourage that behavior, but if I can make money off it, sure. Great. Yeah. The last thing I should know is I'm also co organizing a conference called Squiggleconf, which is happening in October October 3rd in Boston, and for excellent web dev tooling, things like Typescript and Go and Zig and Rust and all this stuff. So that's a lot of time too, and I'm really excited about it.
- [56:56]
Pavel Borkowski
Does it have any link that we could put in the description?
- [56:59]
Josh Goldberg
Yep. Squigglecraft.com?
- [57:01]
Pavel Borkowski
Easy as that. Thank you so much for your time. That was very interesting and looking forward to also the conference and recordings.
- [57:09]
Josh Goldberg
Yeah, no, thank you. This was a great interview. Cheers.