Monday Monday open wide dev fans get ready to stuff your face with JavaScript CSS node module barbecue tip get work Well, it's off skill web development the hcs the karaisius the tastiest web development treats coming in hot here is West Barracuda boss and Scott El Taroloko Welcome to syntax on this Monday. Hey, sweet treat. We're gonna be talking about modules in node This is something that's gonna become more and more relevant as time goes on here So I figured it was a good opportunity to take the time to maybe give a little bit of introduction to what the heck modules are And node and maybe how they're different from modules in the browser My name is Scott Tlinski and I'm a developer from Denver Colorado and with me as always is Wes boss. Hey everybody good to see you Hey, good to see you to Wes This episode is sponsored by one of our sponsors Which is also good to see this sponsor because we absolutely love them over here at syntax and that is sentry at sentry.io Now sentry is the service that you need to solve all of your JavaScript node Anything issues, it's not just JavaScript Let me tell you that century works with just about every single thing you could possibly use not to mention that just about Everybody uses sentry from Airbnb to Disney to PayPal Oh peloton with their cringy ads and Microsoft and Dropbox and all of these people I was looking through logs on my Mb TV server the other day and I was like just looking through the logs and I saw a century log there I was like oh, I got her everywhere everywhere everywhere and let me tell you back in front end doesn't matter Century works for you.
It tells you what happened when the when the bug happened it gives you a whole trail of events There's a click on this on this particular element as in we received a 500 error Now, what was that area? What was the status of that error? You can even tell it which version control commit? Introduce the bug you can attach your source maps You can see the changes of how many bugs over time has happened in your application.
You can ignore bugs for instance We get this really it's like a an error that frequently comes from a Firefox extension that a lot of people use and that's not a bug That I need to see so guess what ignore it I don't want to see that thing anymore because it's not a bug with my application, right? So sentry gives you all that abilities and more to again work with every single thing You need to know to really dive into what's going on with your site and how to fix and solve your bugs head on over to sentry Dot IO and use the coupon cotasty treat all lowercase all one word and you'll get two whole months for free And that's more than enough time to try out because we absolutely love sentry and you will see instantly why okay So modules and node before I want to start get to in depth with this episode You have done quite a bit more research on modules and now that I have so I'm going to ask you some questions And first I want to start off with how they were sort of done before because one of the reasons Why I don't know a whole ton about these is because within my media or setup which I'm using You just had access to the module import syntax and I understand that those aren't actual modules But in the past you may have used import syntax on a node application and how might you have done that? Well, really all that's happening is that it's babble and babble is just converting your code into something that node can't read rather than Actually nodes supporting those modules. So I'm really interested in knowing what are the benefits of using these modules compared it to a babble Configuration that compiles it back down to the standard requires syntax.
So let's get into it here and let's learn a little bit about node modules Yeah, so no modules were unflagged. They're still experimental and they've it's funny I went back and found a tweet from myself from almost two years ago and when I was about to release my node course I said like should I just it was still experimental, but I was like, it's probably fine And I almost released the node course and it's two years later And they're still working on it, which is not not any shade on them. It's not like they're dragging their feet or anything It's just that this is huge in the language and if they get it wrong then we have to live with it for the rest of our lives So they're just spending a lot of time listening to browser developers, node developers package authors making sure that like everything works well together So they're no longer behind a flag when you want to use them So if you're on node 13.2 or higher, you can just start to use them However, they're still missing features and it's still experimental. So yeah, that's that's kind of the caveat of this episode So the way that node modules work right now is that they use a single common JS meaning that you have a file Which is a module and you can either module dot exports like a function or an object or something And that's the main thing that that's the one thing that's exported from that file or you can do exports dot exports dot name exports dot age and you can you can export multiple things from that So it's kind of the same thing as exporting an object But the reason we have that is because sometimes people want to export a function from that and you just module to export the function And sometimes you want to export multiple functions or an object or multiple properties And that's where you use exports dot now We're gonna be using es and that stands for ECMAScript modules now in JavaScript We have a spec as of ESX to have modules in the language and node is making it available for us to use that syntax Since we're already using that syntax in browser land So there's been a huge effort as to like move it over however It's really hard because we have this huge ecosystem of your own authored code Which is written in common jazz and then you also have this huge like hundreds of thousands of modules in NPM And almost all of those are currently written in common jazz And we need to be able to have this big in-between period while we're moving things over as our own code bases and as our libraries get updated to Yes, so we're just gonna like I guess in this episode So just sort of detail like where it's at right now and how it will work and And then we'll have some suggestions as in terms of tools you can use to make the migration easier or whether you should just sit on your hands for Another six months a year So how do you do it?
There's a couple different ways you can do it, but I'm gonna be assuming that okay I want to start I want to rewrite my code base in or I want to move my code base over to using esm Which is ECMAScript modules. That's what we use in the browser So the way that you can do that is you go into your package dot JSON and you switch your project over by default Your project will be using common jazz And if you want to switch your project over to using ECMAScript modules You can go into your package JSON and add a type property and you set that type to be module And that will that will switch it over now if you do that then then all of a sudden you have to rewrite all of the other files They're all talk about a second There are better ways to slowly do this but I was gonna say yeah cuz that seems like not an option for a lot of people in a migration Yeah, you can't just flip it over So maybe I should maybe I should say that approach first So if you want to move over one file at a time without breaking anything You don't put this type of module in your package JSON and you do it file by file And then the way to do that is you have to use the micro Jackson script extension Which is the dot MJS which people curl up in in horror of doing that and at the end of the day the node needs to know How your files should be interpreted? So you either do that cart blanche and you put a type of module in your package JSON or you do it file by file and use the Dot MJS extension on your esm ones So my idea would be that you just start coding every time that you refactor a file you rename that to dot MJS Until you get to a point where all of your files are now MJS's and then I would flip that switch and rename everything back to dot JS So that would that would be like one way to go about I've got some other options as well But then you gotta rename all those files. Yeah, you're your get history is goofed up.
Oh, well sucks I was thinking like what would be the downsides to doing some sort of like a babble thing for your transition? That's coming let me give a sec So the other option is is that you can flip it to type of module in your package JSON Like we said and then you start to use all of those imports you have to either go through every common JS file You've written which has a require in it and flip that over to import or you have to rename those files to a dot CJS Which notes to note that it is common jazz which is kind of a bummer as well And I should say like this is not that they didn't think of this there's a lot of there's a lot of like gotcha's in terms of how the different modules systems work and Babble modules aren't following the ECMAScripts back and that's why it's so easy for babble modules So there's a lot of like people throw in shade on it and there's a lot of hard work that's been done here So maybe like pump the brakes before you send a mean tweet about something like this because it is a much harder problem Then it seems on the surface. I've dove into it It all has to do with the fact that ECMAScript modules are statically evaluated meaning that you can tell what the exports are from a common jazz module just by scanning the file whereas a No jazz common jazz module like you can you can import and export things as part of the code when it's run Which is like you could generate an export when the files read it's parsed and then you could generate an export you can't do that On the other side at least that's my understanding of going into it. You can read the thing yourself and that changes quite a bit, right?
Yeah, well I think for most people it doesn't which is why you're able to use babble and not have a problem at all with it And how I actually ended up just using babble on my project and it just worked, right? So I think for a lot of people it probably doesn't matter But there are some sort of use cases here and there that it comes to importing and exporting So at some point you're going to need to import things from a common jazz module into a yesM module So the way that works is that you just use import and then node will know that you're importing it from a common jazz module But with the import syntax and it will map that import into into just like a variable So you can use like import express from express and even though express is a common jazz module and you're using the import section It will work the downside to that is it named exports don't work currently so if you are importing use effect and Use reducer from react and let's assume react doesn't ship a yesM package then that doesn't work You have to import the whole thing as react and then use the methods off of that now that will change because that was a huge Pain point for me that eventually made me saying this isn't ready for me yet Yeah, that would be tough I have to read a lot of code in node land you can use destructuring you can do something like const curly bracket use reducer equals or Choir react, but it doesn't work yet And apparently there's plans to make it work if you go to github.com forward slash no jazz for its module modules You'll see a list of everything they want to implement yet And at the top of that list is being able to use named exports from a common jazz module because that's not Something you can change yourself because you have to wait for every single package and npm to be updated to a yesM Which might not ever happen there's lots of packages out there that are just done Yeah, they're never gonna be updated, but there's still good packages So like my question is here Like what would be the approach to move it because what I ended up doing is I just went whole hog searched for require and just went Through every single instance like hundreds of require statements I replaced them and it worked but like that you can't do that for most projects, right? So the solution is what you've been asking is use this node module called esm It's written by John David Dalton who wrote low-dash as well And it allows you to just use both and it just works so you can you can use named exports you can use your imports And this code was actually forked off of meteor which Scott's been using for like four years, right? I love it.
Yeah, yeah, and I'm excited about meteor's future with another there's a new ownership behind it But yeah, it's one of those issues that I've always been like every time I start a project that's not meteor and I go import Yeah, you know FS right whatever I'm like, oh, I can't do this without sitting up a whole babble config And then I gotta have a separate web back thing for my server. Yeah, don't babble confit It's like man meteor made that so easy that it was just like it just works just works TM, you know Yeah, so all you have to do to get this thing working is when you run your app with like node index JS You just have to do node dash r esm and that will require the esm package first And it'll do a little bit of magic and then run your app and it just works And it's great and I bet that the node implementation will work like this eventually but until then this is what I'm recommending That you go ahead. I don't think it's all that great Especially if you need named imports like I was trying to import some packages from like keystone and it was called like Graph QL and I was like import graph QL from graph QL But it was a named export so I was like what do I call this thing that I import and then access the method off of It's just like a naming problem I don't even like know what to call this thing if I want to import all right Yeah, you can't do structure it as you import it. That's not part of esm spec Which is a bit of a pain so it's not ready yet.
It's looking really really good I'm really happy that it's there but if you are using the library ecosystem, I would reach for this esm package Yeah, cool. All right. Well that I think that clarified a lot of things for me This is one of those non issues that I've had for so long just because I've never I haven't looked at like a require statement I really need to just just because so no, this is absolutely fascinating I'm gonna keep up a little bit better on this overall Development of this within no just to know what the differences are here I was thinking that they would just flip a switch and all this and everything would be PG keen and it would all just work correctly But no it looks like it's a little bit. Yeah, yeah There's so much little fiddly stuff that they have to think about it also things like importing JSON files You can't just do that as part of esm because it's not a JavaScript module But in node you can just require a JSON file and it will load that object into your variable So they have to sort of like webpack they have to build a bunch of these different loaders And I'm really hoping that they're just built in and they just work and I'm really hoping that you don't have to have like a node Pack file that you have to config probably but they're very much like we don't want to have to have a whole lot of config The only config you have to do is have a type of module or you have to use the microjax and script or the cjs script Cool.
Well, thanks for clearing that up with yeah, no problem Hopefully you learn a thing or two and I'm sure we'll update it Maybe in six months or so to see where we're at with this type of thing go to the node JS modules github repo I'll link it up in the show notes and you can see a Sort of the things that are still outstanding with this awesome. Well, we will catch you on Wednesday Where we're gonna be talking about Pika Pika back Pika back Pika chew package I'm recording this right after this episode and I'm glad we had this because we're both in the headspace of modules ESM modules are the way forward and Pika package as far as I know is trying to solve this as well package building reimagined Yeah, so yeah, but that one is gonna be really exciting alright talk to you later Please head on over to syntax.fm for a full archive of all of our shows and don't forget to subscribe in your podcast player Or drop a review if you like this show