State of the Node.js core with Colin Ihrig
===

[00:00:00] 

Noel: Hello and welcome to Pod Rocket, a web development podcast brought to you by Log Rocket. Log Rocket helps software teams improve user experience with session replay, error tracking and product analytics.

You can try it for free@logrocket.com. , I'm Noel and with me today is Collin eig. , Collin's, a software engineer working on node js, , including the core technical and steering committee, , and a lib UV collaborator.

uh, He just gave his talk, the state of no js cor, , at this year's node conference. Welcome to the show, Colin.

Colin: Thanks for having me. , 

Noel: before we delve into the talk and, , and unpack it a little bit, , can you tell us a little bit about your experience in, \ web related technologies and node and how you found yourself in the position you're in now?

Colin: Yeah, so probably, gosh, like 10 years ago at this point. I had heard about node js, , for a little while, but hadn't really done too much with it. And so I got my first job, , working as a node developer full-time, [00:01:00] and I actually wanted to start writing a book. , so. ~You know,~ I decided I wanted to write a book about no js.

, so I did, \ , really deep dive into the code base so that I could, , write about it, , and, put it to use at my day job. , and in the course of writing the book, I saw a thing or two in the code base that looked like maybe they could be improved. , So after I finished the book, I went back and, , actually started sending pool requests to fix up those things that I noticed.

, and then one thing just~ kind of~ led to another, , and kept working on, I guess more ~and, ~and bigger issues. , and then eventually I was asked to become a collaborator on the project. , and this was back when joint, , the company that originally was like the corporate steward of Node was still running the project. And then, ~you know,~ shortly after that, , there was, I don't know if you remember, there was ~a,~ a big fork, , called I O J S where the community~ kind of~ took the project in its own direction cause it was ~kind of~ unhappy with the corporate stewardship. , And then, ~you know,~ they formed their own technical steering committee and I was asked ~to,~ to join that.[00:02:00] 

Then there was kind of the reconvergence where Node and I O J S came back together. , and what was the node JS Foundation? It's now the Open JS Foundation. , and yeah, I've, I've just really been working on the project since then.

Noel: Nice. Yeah. ~Like, , kind of~ as Node went through those pretty large shifts in, ~, I dunno, like ~the structure, the ecosystem, ~how, like how did that, that,~ how'd that ~kind of~ impact you day to day and how ~you, your, I guess,~ your relationship with the project.

Colin: , so in, , in my day-to-day, I would say, ~you know,~ by the time the fork happened, ~I,~ I was working at Walmart Labs, , who at the time was ~kind of~ really big into node. , the happy JS web framework ~kind of~ came out of there. And so I, that's where ~I,~ I really started getting into open source. , I O J S was interesting because, ~you know, the,~ the community was moving in that direction.

I was contributing there, but still ~kind of~ contributing to the original node project because that's what we were using at work. , and I O J S, ~you know,~ as cool as it was, it had ~some,~ some problems where it was overcorrecting for some of the issues with the original node project. So the community had been upset that, ~, You know, ~joint wasn't merging [00:03:00] patches as quickly as they would like, ~or,~ or taking V8 upgrades ~as,~ as quickly as they would like.

And then I O J S went in the complete opposite direction and it was just like all of these commits landing all the time. And ~like~ there was no real concept ~of,~ of what was stable and what wasn't. So ~like, you know,~ I was having fun working on both projects, but as far as my day-to-day,~ like I, you know,~ we couldn't really rely on iOS at work, so it was just ~kind of~ like ~a,~ a side hobby project, 

Noel: that makes sense. Yeah. ~I,~ I think ~that~ that is probably as ~good a~ good a segue as any need to like~ kind of~ get into ~the,~ the current state then of Node and ~what you,~ what your talk focus is on. ~. Is there, like, it's, ~we're in ~like~ kind of mid, early 20, 23 right now. ~, what is kind of, what,~ what is the release schedule looking like for note?

I know 20 just came out like a couple days ago. ~, what's, like,~ what's exciting there and what should devs be looking at?

Colin: , so I guess let's unpack ~the,~ the release schedule first. ~So, ~, like you said, node 20 just came out, , on April 18th, I believe it was. So that's gonna be , our current release line. , Now we have an official long-term support schedule. This is one of the things that ~kind of ~came out of ~the,~ the merger back between Node and I O J S, ~you know, back in 15,~ is we needed something that could move quickly [00:04:00] for, ~you know,~ developers to be happy with, but something that could be stable enough for, ~you know,~ large enterprises ~to,~ to be able to use.

, and so what we landed on is, ~Every~ twice a year in, , April and October, we have a new major release. So this major release was node 20 in October, we'll have Node 21. , so ~the,~ the even numbered releases that come out in April become what we call our current release. , which means, ~you know,~ we land all of our commits in the main branch ~of,~ of the GitHub repository, and then the things that are not breaking changes get pulled.

Into the current branch. , and so everything \ , that lands in Maine now until, ~you know, ~, I guess October, , will get poured into Node 20. , as long as it doesn't break anything, , at least not intentionally. , and so. Then after six months,~ months, you know,~ once the next release is ready to come out, , the even numbered releases go into what is called Active lts, where ~they,~ they start getting fewer and fewer, , back ports ~of,~ of commits.

So, ~you know, you,~ you might have to wait a little bit [00:05:00] longer for the newest features to get there because ~we,~ we wanna make sure that things get released on the current line before they get back boarded so that enterprises can really have, ~you know,~ as much stability as. , and then similarly we have ~the,~ the odd-numbered releases that come out in the fall.

Those ones do not become, , lts releases. They actually are the current release for about six months and then go into a very short, like maintenance period before their end of life. So right now, that's node 19. Node 19, , is now in maintenance, I believe, and we'll go end of life within the next like month or two.

So ~that,~ that's ~kind of the,~ the way things generally work. So as far as active lines go, right now we have 14, 16, 18, 19, and 20. Node fourteen's gonna be end of life at the end of April. , node 16 was supposed to be end of life next year, but because the version of open SSL that ships with it is also going end of life earlier than usual, , we decided ~to,~ to~ kind of~ truncate that as well, to avoid, ~you know,~ having people running an insecure version of node in production. , node 18 is where [00:06:00] like all of. ~like,~ stability, but also the good improvements are currently landing. node nineteen's gonna go away soon, as I said. And then node 20 is ~kind of, you know,~ the more cutting ~edge,~ edge release right

~I was just gonna say, so that's, that's kind of the, the layout of the, the long-term support schedule as it stands right now.~

Noel: Yeah, ~that, that,~ that makes a lot of sense to me. I feel like ~this is,~ we're in kind of a unique position here where I think that there's gonna be a lot of, , users or, ~you know,~ organizations that are migrating now because we have 14 and 16 end of life thing in ~like ~such a, ~you know,~ close proximity to each other in a somewhat unique way.

, so would you advise like most of those individuals or groups like look. 18 or ~look like,~ look at 20 as their target.

Colin: So the general recommendation is you should be looking at 18, , with 14 being, ~you know,~ weeks away from being end of life. Definitely need to get off of that. , No point really migrating to 16 at this point. , it's like I said, it's gonna be going away in September. ~, there~ there's not a huge gap, , when you try to upgrade between these versions.

So you know, there will be breaking changes, but not all breaking changes affect everyone and, ~you know,~ most people can. Really just [00:07:00] upgrade without even noticing these breaking changes. So node 18 is still gonna be supported. , it's gonna be active lts through, I believe, October of next year. And then it's gonna go into a maintenance period all the way up until ~like~ 2025.

So, ~, you know, you can,~ you can definitely settle on node 18. It's still receiving new features and things ~once they,~ once they're de and stable enough. , so that 100% is the recommendation in general.

Noel: Yeah. Yeah, that makes a lot of sense. I guess ~what,~ what leads to your, , like hesitancy to recommend 20.

Colin: ~the current releases the, like I said,~ the idea is we want to get new things that land in the main branch in people's hands. , but we still wanna have the, ~you know,~ lts to be stable. And so sometimes things do land in the current branch that are, ~you know,~ bugs or regressions. , this is happening a lot.

Less frequently than it used to. , but even with the node 20 release, ~we,~ we had ~a,~ a regression, , around e s m loaders and an out of memory error. , I think it gets into some loop ~and,~ and just ~yeah,~ eats up all your memory. So ~the,~ these are the types of things where ~it's like, you know,~ we don't expect [00:08:00] these things to happen.

~, Right. They, ~they do happen. They can really, ~you know,~ impact you~ if you're,~ if you're not careful. So unless you absolutely need the latest and greatest features, which most people don't, they just want them, um,, then you should definitely stick to the lts releases.

Noel: ~that makes,~ I guess ~kind of~ while we're here, I've always ~kind of~ had ~a,~ a personal curiosity here is. In your mind, ~who,~ who are the people that are reaching for the odd number releases? Like, ~you know, in that,~ in that time when 19 was ~kind of~ the, ~you know,~ active version that Pre 20 ~do, do you think,~ did you think a lot of people would reaching for 19 were like on projects they intended to carry to production?

Or was it mainly people that just ~kind of~ wanted to test out new features? Who were you thinking about? ~Well, you know,~ when discussing and making decisions around ~those,~ those odd number versions.

Colin: So I, I really think that ~as,~ as developers, we always want to have ~like the,~ the latest and greatest and, ~you know,~ new shiny features. ~You know,~ even ~I,~ I'm currently contracting at a company called Platform at, and ~you know,~ there's been discussion about ~should we, you know,~ should we move off of 18 to 20?

And I don't think that's gonna happen, but a, it's, ~you know,~ the smaller companies, , who, ~you know,~ don't [00:09:00] have ~the,~ the huge. Business interest behind it to ~try,~ try to keep things as stable as possible, or~ kind of like~ persuaded by, ~you know,~ individual developers. , I think those are the people who really target it.

, and then there are people who, ~you know,~ a specific feature comes out and you actually need that feature. That's a very small subset, but those are the, also the people who I think would be driven to adopt non lts.

Noel: Yeah, I think that makes a lot of sense. ~Is this, I, I mean, I,~ I honestly follow node's versioning. More so than any other language at this point.~ Is this pattern like borrowed from anywhere else or is this, is this kind of unique to the node ecosystem of like this odd even, you know, every six months or, you know, some cadence having lts and non lts?~

Colin: ~, I believe it was adapted from, from a Linux distribution, but honestly, it, it's been so far, like, so long ago now that I don't remember. But yeah, it was, there was a lot of brainstorming that went into it and I, I think it kind of borrowed from some existing projects.~

Noel: ~Yeah. Yeah. Again, like I'm sure, I'm sure there's other things out there and there's listeners that are like, oh no, like this, all these things did this a long time ago. But yeah, I'm, I'm not, , I'm not knowledgeable of them at this point. ~, so like, , we talked a little bit about ~like~ what should drive devs to pick a different version, and you said that there's ~like~ some specific features that may point them anyway.

Is there anything, ~, You know, ~You know, devs that are ~maybe working working in, like,~ looking for any specific technical capabilities or anything that you might recommend, they check out 20 over 18 ~as a, ~as a target right now,

Colin: , so ~I'm trying to think of some of the, the major, , features that came out. I mean, you know,~ we got a stable test runner in 20, but that is not usually something you need to upgrade ~your,~ your production deployment for. , there's a new version of v8, but it doesn't have anything that's really like, Earth shattering.

, there's a new [00:10:00] permission system that's unstable, so definitely don't recommend running that in production yet. ~, so yeah, I mean, I mean,~ just looking through ~the,~ the list of things ~in,~ in V 20, nothing really jumps out, at least to me as, ~you know,~ we have to have this and we need to upgrade. but ~you know,~ some people might feel differently.

I. 

Noel: Hey, uh, interjecting quick here to remind you guys that Log Rocket offers session, replay, issue tracking, and product analytics to help you quickly surface and solve impactful issues affecting your user experience. With Log Rocket, you can find and solve issues faster, improve conversion and adoption, and spend more time building a better product.

~I mean, yeah. Go people, listeners, go check out the, the. Feature list and see what you need and make, make an informed decision. , but~ you mentioned the V8 project there and ~you talk,~ you touched upon it ~in your,~ in your talk as well. Can you give us some context ~about,~ around what V8 is and why developers should care?

Colin: Yeah, so V8 is, I would say probably the single most important dependency that node js has. It is the JavaScript engine that runs inside of Node. , it's also inside of Chrome, , developed by Google and. ~You know,~ anything that's in ~the,~ the JavaScript language spec really comes from v8. So [00:11:00] even in, in the Node project, we'll get a lot of people showing up, asking for, ~you know,~ add this language feature, and we tell them like, no, ~that's,~ that's not the way it works.

~You, you know,~ you would have to get it into the language from there. It would end up in V8 and then eventually it would end up in Node. , but yeah, so ~it's,~ it's a massive project, , written in c plus plus. ~You know, not, not the most well documented project out there. I think that might be intentional. but, you know, node just wouldn't exist as it is without ~

Noel: Yeah. So ~what, what, ~, what are the upgrades to V8 that, ~, kind of, you know,~ 20. Exposes or, ~you know, like, , like ~empowers or, ~you know,~ allows devs to utilize.

Colin: ~So the,~ the V 20 release shipped with V8 11.3. , One of the big things that~ isn't~ is there is for web assembly developers, , tail call, , optimizations. So this can actually turn certain recursive functions into essentially a loop. , so that can save you a lot as far as like memory ~and,~ and whatnot. , there have also been ~some,~ some new APIs, so like.

String dot, prototype.is well formed and too well formed. ~, array,~ array buffers can, ~you know,~ be resized ~and,~ and global shared array buffers. ~, it's not, you know,~ again, other than ~the,~ the tail call optimization for web assembly, nothing in that list really, ~you know,~ jumps off the page. To me, it's more of [00:12:00] incremental ~pro~ progress.

That's nice to.

Noel: Yeah, sure. Functional programmers everywhere though are, ~you know,~ rejoicing at the, at tail call optimization, so it's all good. , I have a note here about like web platform compatibility. Is that just the. Web assembly stuff or ~is there,~ is there additional stuff in there that might be noteworthy?

Colin: , yeah, so web platform compatibility in general is, ~you know,~ node was written, ~you know,~ back in 2009 originally, and, , a lot of the APIs on the web just didn't exist. So, ~like, you know,~ node still supports callbacks even though we have promises and async wait. ~, You know, all,~ all these new ~like~ web streams ~and,~ and things like that, that have been added to the web platform so that you can ~kind of~ run the same code in node or browser or another, ~, you know,~ server side JavaScript runtime if you wanted to.

, and so the web platform compatibility really gives ~like, , you know, a,~ a single target for developers to write their code so that it'll run in as many places as possible. , and so like back in the day, ~it, you know, like I said, ~node predated a lot of these APIs. And then once these APIs started to be created, node was also ~kind of~ slower to [00:13:00] adopt them.

~, You know, a lot of people,~ for example, a big one is fetch. , fetch is used to make H DP requests. , note already had an HTP library. So ~a lot of people,~ a lot of the pushback there was why do we need fetch? You can just use,~ you know,~ the HDP module. , and the people just kept pushing for it and making the case that like, you know, I wanna be able to run the same code in the browser ~as,~ as in node.

And so, ~you know,~ slowly but surely, I think the project ~has,~ has come around to, ~you know,~ web platform compatibility is I. , and so it is ~like~ an explicit goal of ours now.

Noel: ~Yeah. , I, I,~ I. Send both sides of that argument, I think. But yeah, like~ it is,~ it is always nice as the end user just like, ah, I don't have to think of it. ~Like,~ I encountered one of those just this weekend working on a ~side pro project and I was like working on, , a, a~ felt project and I was like, it'd be cool if I could just write the, I was like, oh yeah, fetch, I can just use, it'll work everywhere now.

This'll be great. No big deal. Can run it in the SSR or in the browser and either will be fine and look at us. Go. , yeah. ~Is there any, ~, I feel like fetch is the obvious example everybody reaches for. Is there any other ones that are ~kind of like, ~, in this compatibility, ~you know,~ mind space that are like top of mind that a lot of devs have been pining for?

Colin: Yeah. So ~I mean, and ~you mentioned fetch. And fetch comes with ~some,~ [00:14:00] some globals like request object and response object that, that are standardized. , as instead of, ~you know, ~if you're using like an express framework and you get. They're rec and res objects that are ~kind of~ more custom. , but ~there are,~ there are all kinds of other ones.

So web streams are a big one. ~So like, ~, node has their own streams implementation, , but it's very specific to Node and, , there's actually like multiple iterations of it in there. ~They're,~ they're ~kind of, you know, ~Not the most fun thing to use. , so web streams came along ~and,~ and standardized that for everyone.

~, we ha ~we do have an implementation of that in Node. We also have adapters so that you can go to and from, , like between node streams and web streams. , , a a really like subtle one that I think is very useful is structured clone. so being able to like clone objects in a way that doesn't require you install low dash and things like that is nice to

have. Web crypto for doing ~like~ cryptography stuff ~on~ in the browser. And you can also, ~you know,~ do it ~in, in,~ in node js instead of nodes custom crypto module. , event target, which is basically the web's answer to nodes event emitter. , but yeah, ~there's, there's, ~there's a lot of them [00:15:00] in node. ~you know,~ just, they don't always necessarily 

stand. 

Noel: Yeah. It's like one of those things that's ~kind of~ creeping in ~and everyone, everyone, like~ people probably don't. That they're benefiting from it when it's there and available, and they can use ~the same,~ the same, , libraries and functions. , you mentioned the test runner just ~kind of, kind of~ kind of pulling us ~out of,~ out of ~v8,~ the V8 world here, but ~what is the,~ what is the new test runner?

How does it work?

Colin: ~So the test.~ So I get a little excited talking about the test runner cuz , I wrote it initially.

Noel: nice.

Colin: So, ~you know, the,~ obviously,~ you know,~ people are writing all these projects for their job, these JavaScript projects, and then you need to install, ~you know,~ a linter, a test runner and things like that. , and I have ~kind of~ a phobia about installing things from M P M just because there's always so many security issues.

Whether it's, ~you know,~ malware people intentionally sabotaging their own modules and things like that. So~ I,~ I really try to keep my dependencies ~as,~ as lean as possible. , and one thing that I always found that I was installing was a test runner. , And, ~you know, I,~ I was very happy with Lab, which is the test runner out of the Happy JS ecosystem because, ~, you know, I,~ I know about ~the,~ the code [00:16:00] standards that go into Happy.

~, you know,~ they're very also reluctant to rely on outside modules ~and,~ and things like that. , and so one day I was doing something and an ES link upgrade actually broke lab for me. , and so ~that, you know, I,~ that was just ~kind of~ the last straw to where I was like, you know what? I think we need to have ~a,~ a test runner in node.

Somebody had already opened an issue about it, so I just decided to start working on it. And originally it was supposed to be as minimal as possible to be able to run tests. , but other people have ~kind of~ come along and started contributing and ~it's, it's,~ it's grown some other features, so ~like.~

Instead of just being able to have one type of syntax for tests ~now,~ now you can do test like you would with tap or tape, or you can do describe an it like you would with Mocha and jest. ~what else?~ There's, , experimental code coverage there. , mocking is built in, , support for, ~, you know,~ running from the command line.

You can either. ~, you know,~ no ~dash~ dash test and~ it'll pick up, you know,~ it'll look for certain files and execute those for you. It runs every file inside of its own child process, so it ~kind of~ keeps [00:17:00] things isolated. , supports different types of reporters. So,~ you know,~ nice, colorful, user-friendly output ~or,~ or tap, which is more ~like, ~machine readable thing ~that ~

~across, ~

Noel: ~compatible stuff. Yeah. Nice. Yeah.~

Colin: ~yeah. So, yeah, it's,~ it's really coming along nicely. ~, you know,~ it's a little over a year. We just marked it stable in node 20. , so ~I,~ I definitely encourage people to go out there ~and,~ and try it out. , there's been some articles written about it online as well as the documentation. , and if anyone has any, ~you know,~ questions about it, feel free ~to,~ to p.

Noel: Nice. Yeah, check it out. I'll check it out for sure. ~It sounds,~ it sounds like one of those that hopefully just ~like~ can become the de facto and we're all using it in five years and like ~that's,~ that's the way it is. 

Colin: , I don't think we'll ever get there just because ~they're~ a, it's not really designed for anything related to the browsers. And b, just, ~you know,~ people are so opinionated ~on,~ on what they expect out of a test runner. But, , if you don't wanna install anything from MPM and ~you know,~ you're building something for Node, not necessarily the front end, then~ I,~ I do think ~it's,~ it's more than capable at.

Noel: think ~like,~ especially ~like if you're,~ if you're in the module space or something, ~like~ if you're writing known modules or something, especially for the backend like it, and you want to keep it lean and clean, ~like,~ I think ~that~ that will be super, super [00:18:00] handy, , for devs. , how about, , util dot parse ARGs?

I have a note on it as well. What does it do?

Colin: Yeah, so that was another one of those features that. ~You know,~ a lot of people need it, and there are a bunch of different modules out there to do it. So~ what it does is handles, ~, when you wanna write a cli, , it handles parsing the arguments for you. So you can define, ~you know,~ a schema, say I want to have.

A specific argument that I wanna be treated as a string versus one that I want to have treated as a bull. ~, you know,~ I want to have this flag, dash, dash fu, but I also wanna have a shorthand of dash F so it, it can do all these things ~kind of like, ~, minimalist and commander and yards, things like that.

, and, ~you know,~ These things get millions and millions of downloads. ~So, ~, a few people took some initiative ~and,~ and built ~a,~ an implementation into core. Uh, , it ~kind of~ landed on the util module because, ~you know,~ it's one function. So we didn't really think it deserved its own top level module. No one was really sure where to put it.

So util is just where it landed. , but yeah, it's been around I think since 18 as well. and it also just got marked as stable in 

node. 

Noel: I think, I feel [00:19:00] like that's one of those that a lot of devs and they're just like hacking on something or wanna try something, they end up ~like~ either having to pull in a library for it, just ~like~ so they're, they can run their little scripts one off and ~like,~ I dunno, interface with some API in a repetitive way or whatever they're doing.

And I think this will be one that'll make it easier for people to do that without having to ~like~ pull in a whole external dependency to just ~kind of~ use this one little piece of it. And they might not need all this ~extra,~ extra code. ~that one's,~ that one's super cool to see. ~Yeah. , let's see. I feel like we've covered a lot in, especially the stuff I've gotten in my show notes here.~

~You, ~I think you mentioned the permission model as well, like in your list of things that were in 20, very briefly tell us a little bit more about that.

Colin: Yeah, so, , It's called the Permission model. ~, I, it's,~ I would say probably inspired by, , the permission model that Dino shipped with, , which is~ kind of ~a competing backend framework. , and ~it,~ what it does is it lets you lock down, Your process from doing certain things. So by default a note application, ~you know,~ it can read anywhere on the file system, write anywhere on the file system, ~you know,~ spawn whatever child process, ~you know,~ spawn RM dash RF on your file system , basically, ~you know,~ do all of these things.

, so the idea behind the permission model is, okay, ~I want to.~ I wanna run my note [00:20:00] application, but ~I don't,~ I don't want it spawning any child processes. if I enable the permission model, then by default it can't spawn any child processes unless I also pass in dash, allow child process. , similarly, you can lock down reads to the file system.

You can lock down rights to the file system. , you can get a little more fine grain so you can say, I'm gonna allow reading from this directory and writing to this other directory, but nothing else. , so ~that,~ that's ~kind of~ the idea behind it and why it's useful, , in practice. , from what I found, because , I also used to work at Dino.

, is that It's more for local development. I. So ~by, you know,~ by the time you're shipping something to production, ~, you,~ you should have these things ironed out. Not to mention you should be running, ~you know,~ inside of a container or firecracker or lambda or some, something like ~that,~ that's gonna handle all this sandboxing for you.

, this is not meant to be, ~you know,~ I can now run on bare metal. I don't have to worry about anything because my permission model is gonna stop ~ev~ everything. it's more for like, ~you know,~ I'm running [00:21:00] locally and I wanna make sure that some MPM module installed is not trying to read from my file system ~or,~ or whatnot.

~The,~ the other thing about it ~is,~ is it's ~kind of~ limited in the fact that it's not per module. ~So if I install, you know,~ if I install, I don't know, I'll just say express. And I don't care what Express does, but then I also install some module that might be a little bit sketchy. I have no way of locking down one without the other. The other thing is as you build bigger and more complicated applications, , they generally need more and more permissions. So ~like, you know,~ I don't wanna allow any child processes, for example, but as soon as I add one feature where maybe three levels down in my node modules, it depends. Shelling out ~for,~ for some system level functionality.

, then all of a sudden I have to open up child processes to ~the entire, you know, ~the entire process. So there are definitely all types of like edge cases and limitations that come with it. ~, Yeah, it,~ it's nice to have, it's ~kind of~ a security in layers thing. , and then the other aspect to this one is, ~you know, ~it's still experimental.

So [00:22:00] there are ~some,~ some caveats that I believe are called out in the documentation as far as like things that are not supported yet. ~there's also, you know, it's a,~ it's a security related feature. So, for example, we shipped a test runner and the very first version of the test runner was, Very rough around the edges, especially compared to where it is now.

We don't really get the same kind of luxury with a permission model because ~you know,~ people are relying security. If it doesn't actually provide security, then you know, we're gonna have CBEs open, people are gonna end up, ~you know,~ trusting it and getting hacked. So like definitely approach it with a lot of 

Noel: Yeah, and I feel like that's just ~kind of designing,~ designing the interface for those kinds of features also has to be. ~I don't know.~ More involved as well, just cuz ~like~ if the norm becomes, you have to pass in, say a flag that's like opening up a bunch of stuff for like any real production project to be working in just becomes the norm.

It's kinda like, well,~ like, well,~ is the permission system even really doing anything for us at this point? Because now everyone's just passing in the flags all the time to open it up, which maybe is ~kind of~ what you were alluding to and you said ~like,~ in production it doesn't, it's not really that meaningful anyway because like we're hoping that these are all running in like [00:23:00] isolated environments and there shouldn't really be anything on the file. As an example, other than what the process is doing regardless. So I ~kind of~ get it, but ~I, I,~ I almost sense like some, ~I don't know,~ not hostility, but it sounds like you have ~like~ a lot of, , kind of reservations about the permission system. Do you think ~the,~ the model was like, ~kind of ~pushed out too quickly or was there stuff you would've done differently or would do differently now?

Colin: , I, I don't really think it was pushed out too quickly. So it, it landed in the main branch, ~, I don't know, a,~ a while back. And then we actually kept it out of a few releases because, , for example, I found an issue where, it would lock down spawn, but it wouldn't lock down spawn sync, so that if that would've been, at least, that would've been, ~you know,~ a CVE

waiting to happen., another person, , another node TSE member, ~, you know,~ was testing it out and found some issues related to, I, I think it was like file system permissions and, ~, You know,~ specifically sim links. Sim links are always tricky because, ~you know, you're,~ you're trying to lock down this folder and all of a sudden it's a pointer , to somewhere completely different.

~, so I,~ it's not that I have hostility ~or,~ or,~ you know,~ any bad feelings towards it, it's just, ~I, I, ~like I said, I used to work at Dino and I [00:24:00] really just found that it got in my way more than anything, but I'm sure there are people ~who,~ who will definitely benefit from it. I just, like I said, be careful with it.

while, especially while it's still experi.

Noel: Yeah. ~sounds,~ sounds like your main advice is not to overly trust the permission system. Now. Use it when you can, but don't, ~know,~ rely on it to,

Colin: Definitely, definitely kick the tires on it, especially if you're a security researcher. ~You know,~ try to poke holes in it. Maybe you can make a little bit of money. but ~we, we would,~ we would love the feedback on it for

sure. 

Noel: That's, ~another good,~ another good segue for us there. ~How, how,~ what kind of help do you guys need? Like if people want to get involved, ~what,~ where are you guys ~really, you know,~ looking for contributors or just, ~you know,~ outside assistance?

Colin: So Node is a very open project. ~It's,~ it's not controlled by any company, so ~there's, there's not like,~

~you're~ you're not gonna have to jump through hurdles to like, get somebody from the company to look ~at your pro~ at your pool requests and things like that. ~You're,~ you actually can have a path to becoming a contributor and a collaborator or TSC member or whatever.

, as far as getting involved, ~I mean, there,~ there are. I think hundreds ~of~ of open issues, and some of them ~are,~ are tagged with like good first issues. So, ~you know,~ just show up, find something that looks interesting to you. ~, the, the,~ the other [00:25:00] contributors will be happy to ~like~ point you in the right direction if you start posting questions.

, don't show up and lick the cookie. So don't show up and say, I would like to work on these five issues. That generally doesn't work out well because then people think someone's working on it. They never end up working on it. And yeah, ~it's,~ it's a whole thing. , but yeah, ~the,~ the community is very welcoming , to new contributors.

so just show up in like any area that you're interested in. We're ~more than, you know,~ more than happy to have help

Noel: ~Yeah. Nice. That's. Yeah, it's,~ it's always good to hear about projects that are, like going through ~the,~ the work of~ kind of~ grooming the backlog and flagging things that might be good places for devs to jump in. ~Like, that's always,~ it's always super awesome to see. , is there anything in particular you're excited about ~kind of in the,~ in the future, near term ~or,~ or longer term, ~, kind of ~node related or even ~kind of~ in the JavaScript ecosystem at large.

Colin: ~, so.~ One is, , something I'm working on. ~I'm,~ I'm in the process of trying to wrap up code coverage for the test runner. ~, right,~ right now the way it works is, ~you know,~ if you have multiple child processes, they all create these different coverage reports. , so being able to merge those all back together in a way ~that~ that makes sense to present to the end user will be really nice to have ~in,~ in my opinion.

, at the [00:26:00] language level ~there,~ there are some interesting things coming, like shadow realms. Async context, and things like that, ~that,~ that look exciting and are also ~kind of~ like standardized versions of APIs that already exist inside of Node, which is always nice to 

have. 

Noel: Nice. Very cool.~ Well, I guess, yeah, is there,~ is there anything else you wanna, , leave listeners with, Colin? Anything else you'd like to call out?

Colin: , I think just, yeah, get out there. , please ~get everyone, you know,~ give Node 20 ish, , a shot. report any bugs that you find, but remember if you're running in production node

18. 

Noel: Cool. Thank you so much for, uh, coming on , and chatting with me. It's been a pleasure.

Colin: Yeah, thanks for having 

me.