WEBVTT 1 00:00:05.200 --> 00:00:09.720 Hello, everybody, Welcome to another thrilling episode. I was going 2 00:00:09.800 --> 00:00:14.359 to say, example episode of JavaScript. Jower, I am Steve Edwards, 3 00:00:14.359 --> 00:00:16.039 the host with the face for radio and the voice 4 00:00:16.079 --> 00:00:18.480 for being a mine, but Dan got to me the host, 5 00:00:18.480 --> 00:00:24.320 so you're stuck with me speaking of panelists. Was I 6 00:00:24.359 --> 00:00:25.239 speaking of panelists? 7 00:00:25.239 --> 00:00:25.640 Now I am? 8 00:00:25.719 --> 00:00:28.600 Anyway, Dan Shapiro is here with me. We are flying 9 00:00:28.600 --> 00:00:31.320 solo today. How you doing, Dan, I'm doing great. 10 00:00:32.119 --> 00:00:33.640 So let's do our usual weather report. 11 00:00:33.719 --> 00:00:38.079 It is cool and rainy here in Portland, shocking for Oregon. 12 00:00:38.119 --> 00:00:39.159 And in April, I know. 13 00:00:39.840 --> 00:00:43.840 How tel Aviv guess warm and sunny? 14 00:00:44.640 --> 00:00:49.479 How did you ever guess? We literally didn't really have 15 00:00:49.560 --> 00:00:52.039 a winter this year, to be honest, it was more 16 00:00:52.159 --> 00:00:55.479 like a bit of a fall. Not that you know, 17 00:00:56.679 --> 00:00:59.079 we should have more rain than we did. But you know, 18 00:00:59.119 --> 00:01:02.320 it's still lovely there at least that and it still 19 00:01:02.439 --> 00:01:05.040 is lovely weather fabulous. 20 00:01:05.040 --> 00:01:06.959 Well it's fabulous for you, it's jealous for me. 21 00:01:07.120 --> 00:01:10.959 But anyway, so today we are going to be talking 22 00:01:11.079 --> 00:01:16.719 about a practical application of pipescript in JavaScript. I'll let 23 00:01:16.799 --> 00:01:20.159 Dan give the details, but we're going to talk about 24 00:01:20.519 --> 00:01:25.159 everything that was involved in Was it a new project 25 00:01:25.200 --> 00:01:28.159 I already forgot. Oh so yeah, I'll let you talk 26 00:01:28.159 --> 00:01:29.760 from here so I don't mess it up anymore. 27 00:01:31.040 --> 00:01:38.840 All good. So basically I had this interesting situation at work. 28 00:01:39.599 --> 00:01:45.599 We have a large legacy JavaScript project that's still a 29 00:01:45.760 --> 00:01:51.280 core part of our offering, and it's under active well 30 00:01:51.280 --> 00:01:55.879 beyond maintenance. It's being actively developed and enhanced and improved 31 00:01:55.920 --> 00:02:00.319 and whatnot. But it's all done in JavaScript on hundred 32 00:02:00.359 --> 00:02:04.640 percent JavaScript because it was started more than eight years 33 00:02:04.640 --> 00:02:09.639 ago and it was never moved over to typescript. It 34 00:02:09.840 --> 00:02:19.759 just stayed JavaScript, and I was looking at introducing typescript 35 00:02:19.840 --> 00:02:24.719 into that project. Actually that project has two parts. It 36 00:02:24.840 --> 00:02:29.360 has a server that's just running on no JS with Express, 37 00:02:30.199 --> 00:02:34.199 and it has a client or front end side, which 38 00:02:34.280 --> 00:02:40.479 is implemented in React. That part actually again talking legacy. 39 00:02:41.319 --> 00:02:44.199 Some years ago before I joined the company, they made 40 00:02:44.280 --> 00:02:48.560 the kind of unfortunate choice to introduce flow into the 41 00:02:48.560 --> 00:02:51.800 front end part for type safety, and they only did 42 00:02:51.879 --> 00:02:56.639 it partially. I didn't want to touch flow yet, so 43 00:02:56.680 --> 00:03:00.919 I was looking at introducing type script to the back 44 00:03:01.039 --> 00:03:04.479 end part, to the no JS part of the project, 45 00:03:05.879 --> 00:03:09.360 and it turned out that it was much more complicated 46 00:03:09.960 --> 00:03:12.560 and error prone than I expected. There were a lot 47 00:03:12.599 --> 00:03:15.560 of pitfalls and gutchas along the way. I kind of 48 00:03:15.599 --> 00:03:18.960 thought that, you know, given that the whole idea of 49 00:03:19.000 --> 00:03:23.680 typescript is to get JavaScript devs onto the bandwagon, that 50 00:03:23.800 --> 00:03:27.960 it should be really easy and straightforward, and it wasn't. 51 00:03:28.520 --> 00:03:33.400 And I even consulted with some typescript luminaries like Matt 52 00:03:33.439 --> 00:03:37.520 Polcock had a lot of great advice and suggestions, but 53 00:03:37.639 --> 00:03:41.120 it still wasn't easy. Also with Jack Harrington and others, 54 00:03:41.639 --> 00:03:45.319 they all had great advice, but it still was much 55 00:03:45.479 --> 00:03:49.639 more challenging than I expected. And the end result is 56 00:03:49.719 --> 00:03:53.000 that I kind of documented the entire process, did a 57 00:03:53.039 --> 00:03:57.400 bit something like an internal blog about it, and we 58 00:03:57.479 --> 00:03:59.960 have this internal wiki. So I wrote the whole doc 59 00:04:00.360 --> 00:04:02.280 about how to do it so that if and when 60 00:04:02.360 --> 00:04:07.560 we do it in another project, it'll be much easier 61 00:04:07.599 --> 00:04:10.520 that time around. And I thought that it would be 62 00:04:10.680 --> 00:04:13.520 interesting and useful for our audience for me to show 63 00:04:13.560 --> 00:04:16.759 this information. I hope that it is okay. 64 00:04:16.759 --> 00:04:20.319 So just to clarify, we're on the front end, you're 65 00:04:20.319 --> 00:04:22.120 still sticking with what was there, right, In other words, 66 00:04:22.120 --> 00:04:25.720 you're going to go with the flow, should we say. 67 00:04:26.800 --> 00:04:29.040 And then on the back end was where you're doing 68 00:04:29.040 --> 00:04:30.120 your typescript upgrading. 69 00:04:30.879 --> 00:04:34.480 Yeah, So the answer is actually that our ultimate intention 70 00:04:34.839 --> 00:04:39.360 is to do typescript on both sides, but I wanted 71 00:04:39.399 --> 00:04:43.600 to start somewhere, and it seemed easier to start with 72 00:04:44.120 --> 00:04:48.319 the just JavaScript part because Flow and typescript, while they 73 00:04:48.360 --> 00:04:52.199 are similar, they're not the same. They're not compatible, and 74 00:04:52.240 --> 00:04:54.680 I didn't want to get into the whole mess of 75 00:04:54.759 --> 00:04:57.680 how I get typescript and Flow working together in the 76 00:04:57.720 --> 00:04:58.759 same project. 77 00:04:59.040 --> 00:05:02.680 Oh you so you wouldn't. You wouldn't replace flow with tithescript. 78 00:05:03.040 --> 00:05:10.439 I would, But these are large projects, so replacing well, 79 00:05:10.600 --> 00:05:15.720 let's put it this way. I really wanted to do 80 00:05:15.800 --> 00:05:20.600 everything gradually. It's important to emphasize this point. So for example, 81 00:05:20.720 --> 00:05:26.120 talking about just to give an an understanding of the 82 00:05:26.160 --> 00:05:29.600 size the scope of the project, So talking just about 83 00:05:29.759 --> 00:05:34.240 the back end part that no JS project, we're talking 84 00:05:34.240 --> 00:05:39.000 about close to one thousand files JavaScript files, about seventy 85 00:05:39.079 --> 00:05:46.519 thousand lines of code, something like thirty five hundred commits 86 00:05:46.560 --> 00:05:50.160 since the project started over seven close to eight years ago. 87 00:05:51.759 --> 00:05:56.639 So it's not a small project. And obviously I can't 88 00:05:57.120 --> 00:06:02.399 move all the JavaScript files over to typescript, all thousand 89 00:06:02.480 --> 00:06:05.920 of all one thousand of them in one go. Now, 90 00:06:05.959 --> 00:06:10.959 there are some automated tools that automatically move all your 91 00:06:11.199 --> 00:06:15.360 JS files into TS and add types as best they can, 92 00:06:15.959 --> 00:06:19.040 using all sorts of tricks and static analysis and whatnot. 93 00:06:19.560 --> 00:06:23.000 I did not want to do that. I was looking. 94 00:06:23.079 --> 00:06:25.079 The way that I wanted to go about it, and 95 00:06:25.199 --> 00:06:28.759 especially after I spoke with some people, is to enable 96 00:06:28.959 --> 00:06:33.079 a gradual migration. And I'll talk about the two ways 97 00:06:33.079 --> 00:06:38.120 in which a gradual migration can be achieved. By the way, 98 00:06:38.399 --> 00:06:42.160 if you want to understand why I'm looking at a 99 00:06:42.199 --> 00:06:46.439 gradual migration, why I prefer this approach, you can also 100 00:06:46.519 --> 00:06:49.040 listen to the interview that I did with Matt Pocock 101 00:06:49.079 --> 00:06:52.120 a while back about typescript, and we also discussed this 102 00:06:52.279 --> 00:06:56.959 aspect about migrating projects, although again we did not go 103 00:06:57.040 --> 00:07:01.959 into the exact details that I'm intending to go into today. 104 00:07:02.079 --> 00:07:07.040 So the idea was to basically introduce typescript into the 105 00:07:07.120 --> 00:07:10.920 project so that we can do the actual migration of 106 00:07:10.959 --> 00:07:15.639 the files slowly over time. It could literally take years. 107 00:07:15.879 --> 00:07:21.160 Is that is that clear? I hope? Yes. 108 00:07:21.319 --> 00:07:23.399 Sorry, I was looking at the Matt Pocock episode so 109 00:07:23.439 --> 00:07:24.560 I could tell people what it was. 110 00:07:25.639 --> 00:07:30.199 Yeah, we can probably put a link in the show notes. Yeah. Yeah, 111 00:07:30.199 --> 00:07:34.000 it was an excellent episode, highly recommended. Wait a minute, 112 00:07:34.040 --> 00:07:35.800 we did two episode with them. Are you looking at 113 00:07:35.839 --> 00:07:38.240 the latest one, the one from like about a few 114 00:07:38.279 --> 00:07:41.680 months ago, or an older one from like two years ago? 115 00:07:42.680 --> 00:07:45.800 Uh? Yeah, five thirty eight. 116 00:07:45.800 --> 00:07:49.120 It was probably a couple of years ago, so we 117 00:07:49.160 --> 00:07:50.600 did more recent one. 118 00:07:51.199 --> 00:07:53.560 Okay, we'll find those and mention them later. 119 00:07:54.360 --> 00:07:59.720 Okay, So again we're talking about one hundred percent JavaScript 120 00:07:59.720 --> 00:08:04.800 product built on top of NOGS with Express. Like AJ 121 00:08:05.120 --> 00:08:08.480 likes it, it uses common JS rather than import, so 122 00:08:08.600 --> 00:08:13.000 it requires it's a legacy project for an API with 123 00:08:13.120 --> 00:08:16.560 the front end side, it actually uses a combination of 124 00:08:17.279 --> 00:08:22.199 Swagger and open Api for public RESTful APIs and actually 125 00:08:22.360 --> 00:08:29.000 graphql with Apolo for the internal private APIs. For unit 126 00:08:29.040 --> 00:08:34.159 testing we used Moca and Chai and it has end 127 00:08:34.159 --> 00:08:38.759 to end tests implemented mostly using Playwright, but that's less relevant. 128 00:08:39.759 --> 00:08:44.840 As I said, almost one thousand JavaScript files, almost seventy 129 00:08:44.879 --> 00:08:49.879 thousand lines of code, and around thirty five hundred commits 130 00:08:49.919 --> 00:08:53.919 since the project started. And again we use squash, so 131 00:08:53.960 --> 00:08:58.840 it's really thirty five hundred prs really rather than you know, 132 00:08:59.120 --> 00:09:00.919 along the way the world a lot more commits, but 133 00:09:00.960 --> 00:09:02.679 they were just squashed together. 134 00:09:03.240 --> 00:09:06.600 By squash you mean, not the vegetable. But when you 135 00:09:06.720 --> 00:09:09.759 do the get merging in, you squash multiple commits and 136 00:09:09.799 --> 00:09:12.039 do one bigger commit exactly. 137 00:09:12.559 --> 00:09:15.679 Just a clarify for yeah people, because you know, there 138 00:09:15.679 --> 00:09:17.799 are a lot of small commits along the way. I'm 139 00:09:17.840 --> 00:09:20.679 fixing this. I'm fixing that they're they're not that interesting 140 00:09:20.840 --> 00:09:23.639 in most cases. You know, you can keep them if 141 00:09:23.639 --> 00:09:30.200 they're really important, but in most cases they're not that interesting. Okay, 142 00:09:30.320 --> 00:09:34.519 So I was looking to enable a gradual migration, which 143 00:09:34.600 --> 00:09:39.559 means introducing Typescript into the project, but not actually moving 144 00:09:39.600 --> 00:09:43.639 the entire project over to typescript. Maybe a few words 145 00:09:43.679 --> 00:09:48.480 about why I wanted to do that. It's really funny. 146 00:09:49.120 --> 00:09:52.759 I also spoke about this with Matt. When typescript first 147 00:09:53.000 --> 00:09:56.399 was introduced, I had a kind of a negative attitude, 148 00:09:57.600 --> 00:10:02.120 you know, when I came to JavaScript. Statically typed languages 149 00:10:02.960 --> 00:10:06.840 like C plus plus and like Java, like C Sharp 150 00:10:07.399 --> 00:10:12.360 and JavaScript. The dynamic nature of JavaScript afforded an amazing 151 00:10:12.399 --> 00:10:17.720 amount of freedom, and I loved it. But as I 152 00:10:17.759 --> 00:10:23.480 became ever more seasoned in JavaScript development, especially working in 153 00:10:23.679 --> 00:10:28.720 larger teams, I came to realize and understand that for 154 00:10:28.919 --> 00:10:36.000 larger projects involving larger teams, for production grade software, you 155 00:10:36.440 --> 00:10:41.519 want something that's more structured and rigid, and you want 156 00:10:41.639 --> 00:10:48.960 something that helps you avoid certain errors that can easily 157 00:10:49.080 --> 00:10:52.759 happen if you're just using JavaScript. You know, the obvious 158 00:10:52.799 --> 00:10:57.440 example is you just misspelled or mistype a property name 159 00:10:58.039 --> 00:11:02.200 and you just get undefined instead of the actual value. 160 00:11:03.120 --> 00:11:06.960 But there's no error in any other in you know, 161 00:11:07.000 --> 00:11:09.960 in any other way, and it seems to run. It 162 00:11:10.159 --> 00:11:13.279 just runs wrong, And that's one of those things that 163 00:11:13.840 --> 00:11:18.759 typescript protects you from. Typescript. Also, the code is much better, 164 00:11:18.960 --> 00:11:22.919 much more self documented, especially if you're talking about APIs, 165 00:11:24.039 --> 00:11:27.399 Especially again if you're talking about larger teams that compose 166 00:11:27.600 --> 00:11:32.960 software from parts, components or services together. You want APIs 167 00:11:33.000 --> 00:11:40.159 that are much better structured and self documented. And the 168 00:11:40.200 --> 00:11:47.039 integration with modern development tools like vis code especially that 169 00:11:48.039 --> 00:11:53.000 does the much smarter autocomplete for you and puts squigglies 170 00:11:53.840 --> 00:11:58.720 if you pass in wrong parameter types or the wrong 171 00:11:58.799 --> 00:12:03.399 number of parameters or whatever. All these are super useful 172 00:12:03.480 --> 00:12:08.639 tools when you're working, especially as I said, in an 173 00:12:08.759 --> 00:12:14.039 enterprise type environment. And these days it's also better with 174 00:12:14.159 --> 00:12:18.960 AI because it gives the AI greater context. By the way, 175 00:12:19.000 --> 00:12:21.039 all that being said, if I need to solve a 176 00:12:21.080 --> 00:12:23.399 lit code type problem, I'll probably just do it in 177 00:12:23.480 --> 00:12:27.720 JavaScript and not mess about with the types. But for 178 00:12:27.799 --> 00:12:31.519 everything else, I find that even though we are writing 179 00:12:31.600 --> 00:12:36.000 those types that ultimately are evaporated out of the code, 180 00:12:36.039 --> 00:12:39.639 because when Typescript is compiled to JavaScript, it basically just 181 00:12:39.919 --> 00:12:44.600 strips out all the types. Despite that fact, I still 182 00:12:44.679 --> 00:12:51.000 find it incredibly useful maintenance for the development and maintenance 183 00:12:51.039 --> 00:12:54.480 of larger certainly of larger code bases, and especially in 184 00:12:54.559 --> 00:12:57.519 this case, the fact that the project was done in 185 00:12:57.559 --> 00:13:02.960 JavaScript and not Typescript was definitely hurting our developer experience. 186 00:13:04.480 --> 00:13:09.440 Just recently, somebody literally introduced a bug that could not 187 00:13:09.559 --> 00:13:15.320 have happened had the project been entirely done in Typescript, 188 00:13:15.879 --> 00:13:19.759 and it didn't propagate all the way to production, but 189 00:13:19.919 --> 00:13:22.559 it was only caught by an end to end test, 190 00:13:22.919 --> 00:13:27.919 you know, later down the line, and it was much 191 00:13:28.000 --> 00:13:31.879 more difficult and expensive to handle than if vis code 192 00:13:31.919 --> 00:13:35.639 would just have put a squiggly under that offending instruction. 193 00:13:35.879 --> 00:13:37.919 So far, so good, so far, so good. 194 00:13:38.039 --> 00:13:40.919 By the way, I totally appreciate the fact that a 195 00:13:40.960 --> 00:13:46.440 lot of front end developers or full stack developers still 196 00:13:46.480 --> 00:13:50.559 preferred to work in JavaScript. You know, you do you 197 00:13:50.720 --> 00:13:54.600 whatever works best for you. For me, after all these years, 198 00:13:54.679 --> 00:13:57.960 I've come to the conclusion that again, for the larger 199 00:13:58.000 --> 00:14:05.360 projects involving multiple developers, certainly I prefer you working in typescript. Okay, 200 00:14:05.480 --> 00:14:10.360 So I have the project, it's pulled down to my computer, 201 00:14:11.080 --> 00:14:13.480 and I want to start. The first thing that I 202 00:14:13.519 --> 00:14:17.240 went about, again because it's a legacy project, is I 203 00:14:17.320 --> 00:14:21.039 want to upgrade, to make sure that node is upgraded 204 00:14:21.080 --> 00:14:25.279 to the latest possible version, ideally to the latest LTE 205 00:14:25.480 --> 00:14:33.159 version LTLS version sorry, long term support version. And if 206 00:14:33.200 --> 00:14:35.600 people are curious about what that means. We had that 207 00:14:36.399 --> 00:14:40.080 conversation with the node guys about the nine pillars of note. 208 00:14:41.720 --> 00:14:46.279 Hopefully you're using something like NVM, the node version management, 209 00:14:46.399 --> 00:14:49.360 so you just you know, find the latest version you 210 00:14:49.360 --> 00:14:53.240 support you can support idea, the latest LTS version and 211 00:14:53.279 --> 00:14:57.279 put it in your NVMRC file. Update to that and 212 00:14:57.960 --> 00:15:01.000 make sure that that it runs and that you can 213 00:15:01.080 --> 00:15:04.240 work with it. Also make sure that obviously that you 214 00:15:04.320 --> 00:15:08.600 were pulled on the latest version from you know, GitHub 215 00:15:08.759 --> 00:15:13.919 or whatever, and that it appears to work properly in 216 00:15:13.960 --> 00:15:19.240 your environment. The next step is to make sure it 217 00:15:19.279 --> 00:15:23.679 seems obvious and explain why it isn't that your unit 218 00:15:23.720 --> 00:15:28.559 tests work correctly. Now you might say, well, obviously, because 219 00:15:28.639 --> 00:15:32.840 otherwise the project will be broken. But in our case, 220 00:15:32.840 --> 00:15:35.879 at least, it turned out that some of the unit 221 00:15:35.960 --> 00:15:42.399 tests had cross dependencies. What that means is that they 222 00:15:42.519 --> 00:15:46.600 used mocks but didn't always properly cleaned the mocks up 223 00:15:47.399 --> 00:15:51.279 the results. Some of the tests actually only passed when 224 00:15:51.320 --> 00:15:53.240 they were run in a particular order. 225 00:15:54.440 --> 00:15:57.480 No, yeah, I've ran into that before. I know exactly 226 00:15:57.480 --> 00:15:58.320 what you're talking about. 227 00:15:59.039 --> 00:16:03.120 Yeah, And it turns out that everything seemed to be 228 00:16:03.240 --> 00:16:07.240 fine because when it was run in the JavaScript project, 229 00:16:07.840 --> 00:16:10.399 it was it happened to run in the correct order. 230 00:16:10.440 --> 00:16:13.759 Otherwise people would have noticed and fixed it a while ago. 231 00:16:14.200 --> 00:16:18.559 But when I actually started moving the project over the typescript, 232 00:16:19.240 --> 00:16:24.840 it turned out that because of the transpilation step, things 233 00:16:25.039 --> 00:16:28.600 didn't run in exactly the same order, and then certain 234 00:16:28.639 --> 00:16:33.840 tests broke. Or I had certain situations where I needed 235 00:16:33.879 --> 00:16:36.120 to touch the business logic, and then I wanted to 236 00:16:36.200 --> 00:16:40.320 run particular tests individually, and I found out that when 237 00:16:40.360 --> 00:16:43.559 I tried to run the test individually, they failed, and 238 00:16:43.600 --> 00:16:46.159 then I went back to the original code and founded 239 00:16:46.200 --> 00:16:49.720 those tests. Even when I ran them individually in the 240 00:16:49.759 --> 00:16:54.960 actual original JavaScript project, they also failed because they only 241 00:16:55.000 --> 00:16:57.399 passed when they were run in a batch in the 242 00:16:57.440 --> 00:17:03.279 appropriate order, because again of mock leaks. I won't go 243 00:17:03.399 --> 00:17:07.519 into the detail of what mock leaks have are. Basically, 244 00:17:08.000 --> 00:17:11.400 it just means that a mock was put in but 245 00:17:11.720 --> 00:17:16.279 wasn't properly removed at the end of the test. It 246 00:17:16.359 --> 00:17:21.079 consequently leaked into the next test, uh, and it impacted 247 00:17:21.119 --> 00:17:23.519 that and in that case it actually enabled it to 248 00:17:24.079 --> 00:17:27.519 complete successfully. And when you just run that test on 249 00:17:27.559 --> 00:17:31.119 its own, it doesn't get those mocks, and then it failed. 250 00:17:31.400 --> 00:17:35.119 So in all the idea, I mean, obviously, I think 251 00:17:35.160 --> 00:17:39.759 the idea there is that tests should be self but 252 00:17:40.119 --> 00:17:42.799 they stand by themselves. I don't know what the correct 253 00:17:42.839 --> 00:17:45.559 term is, right, so you're not dependent upon other tests. 254 00:17:45.960 --> 00:17:47.400 Yeah, for the test to spin up. 255 00:17:47.359 --> 00:17:49.400 Your environment and give you a mock up and give 256 00:17:49.400 --> 00:17:51.640 you everything you need, run the test, break it down 257 00:17:51.960 --> 00:17:52.880 on the next test. 258 00:17:53.519 --> 00:17:56.079 Yeah. By the way, even the fact that you know 259 00:17:56.119 --> 00:17:58.839 a lot of the code has that so many marks 260 00:17:58.839 --> 00:18:02.079 were used were test statement to the fact that it 261 00:18:02.119 --> 00:18:05.759 was legacy code, because ideally, in more modern code I 262 00:18:05.799 --> 00:18:10.039 would use dependency injection and try to avoid so many marks. 263 00:18:11.319 --> 00:18:14.440 But again, the code is what it is, and that 264 00:18:14.599 --> 00:18:23.079 was the situation. So basically the thing was that before 265 00:18:23.119 --> 00:18:26.599 I could actually start the migration to Typescript, I actually 266 00:18:26.680 --> 00:18:30.559 needed to fix a bunch of mock leaks and get 267 00:18:30.599 --> 00:18:34.279 the tests to run properly in the original project before 268 00:18:34.319 --> 00:18:38.240 I even start migrating it over to typescript. So I 269 00:18:38.319 --> 00:18:43.039 verified that all the tests could run individually, and only 270 00:18:43.079 --> 00:18:46.480 then did I actually start the migration process. The next step, 271 00:18:46.519 --> 00:18:52.319 of course, is to install Typescript and initialize it. So 272 00:18:52.359 --> 00:18:56.640 you do youless you're using NPM or yarn or whatever. 273 00:18:56.880 --> 00:19:02.880 You NPM or yarn or MPM installed typescript, you do 274 00:19:03.000 --> 00:19:09.160 Typescript in it. And already here I ran into an 275 00:19:09.200 --> 00:19:18.160 issue because my default assumption was that the installation of 276 00:19:18.319 --> 00:19:23.480 Typescript should be as a dev dependency, because why would 277 00:19:23.559 --> 00:19:28.920 you need the actual Typescript compiler in the production environment. 278 00:19:29.160 --> 00:19:33.319 It's just part of your development pipeline. In order to 279 00:19:33.400 --> 00:19:42.839 actually build the system, the installable part of your project. 280 00:19:44.000 --> 00:19:47.480 You only actually deploy the disk folder or whatever it 281 00:19:47.559 --> 00:19:50.799 is that you're creating. And it turns out that at 282 00:19:50.880 --> 00:19:53.920 least in our case and maybe also in the case 283 00:19:54.039 --> 00:19:58.759 of our listeners, that was not the case. I actually 284 00:19:58.920 --> 00:20:01.799 had to install it as a PRAD dependency. Are you 285 00:20:01.839 --> 00:20:04.839 familiar with the difference between a PROD and a DEV dependency? 286 00:20:05.880 --> 00:20:06.440 Absolutely? 287 00:20:06.480 --> 00:20:09.079 I mean we ran into the same thing, uh in 288 00:20:09.119 --> 00:20:13.480 the PHP world on the back end with composer, where 289 00:20:13.799 --> 00:20:17.559 a classic a similar analog to what you're doing is 290 00:20:17.960 --> 00:20:21.920 PHP stand which is a static analysis tool for PHP. 291 00:20:22.000 --> 00:20:26.160 Where you don't want that, you know, in your in 292 00:20:26.240 --> 00:20:29.119 your PROD build, so you put it as a dependency 293 00:20:29.599 --> 00:20:30.680 use a save DEAV flag. 294 00:20:30.759 --> 00:20:35.119 Yeah. So unfortunately, I actually had to install typescript as 295 00:20:35.119 --> 00:20:38.559 a PROD dependency in our case. And the reason was 296 00:20:38.759 --> 00:20:41.960 that the build. The way that the built pipeline worked 297 00:20:42.640 --> 00:20:49.799 is that it actually created a pod for deployment, uh, 298 00:20:49.920 --> 00:20:53.359 you know, like a Docker pod basically, and and it 299 00:20:53.519 --> 00:20:59.160 actually did sort like a get pulled inside the pod 300 00:20:59.720 --> 00:21:04.279 and then ran the build in the pod. So if 301 00:21:05.039 --> 00:21:12.000 and it only did and it only ran the PROD installation, 302 00:21:12.720 --> 00:21:15.599 so if I didn't put it as product PRAD, I 303 00:21:15.720 --> 00:21:20.000 actually broke our CICD pipeline because it tried to run 304 00:21:20.599 --> 00:21:24.039 the TC as part of the PROD build, and it 305 00:21:24.119 --> 00:21:31.319 wasn't there. Now, ideally I should fix the CICD pipeline 306 00:21:31.359 --> 00:21:34.519 so that it doesn't work this way, maybe build it 307 00:21:34.559 --> 00:21:37.880 into a special environment and then copy the files over 308 00:21:38.039 --> 00:21:41.319 into the PROD environment rather than build in the PROD environment. 309 00:21:42.160 --> 00:21:46.319 But I wanted to reduce the amount of DevOps work 310 00:21:46.400 --> 00:21:49.559 that I actually had to do, and it seemed just 311 00:21:49.640 --> 00:21:54.799 a lot easier to just make Typescript itself a PROD dependency. 312 00:21:54.880 --> 00:21:58.720 It's just an ideal, of course, because you're shipping Typescript 313 00:21:58.759 --> 00:22:05.839 as part of your note modules. It's broad installation. But 314 00:22:06.000 --> 00:22:09.519 you know what, it's so big anyway, it didn't make 315 00:22:09.720 --> 00:22:11.920 that hole that much of a difference in our case. 316 00:22:11.960 --> 00:22:14.400 And as I said, I just wanted to get over 317 00:22:14.519 --> 00:22:16.920 this this blocker, so just. 318 00:22:17.680 --> 00:22:20.359 So just to clarify that, so it doesn't you know, 319 00:22:20.440 --> 00:22:24.440 I'm not a big Typescript user myself used some and 320 00:22:25.759 --> 00:22:27.039 not a real big user of it. 321 00:22:27.279 --> 00:22:28.359 But correct me if I'm wrong. 322 00:22:28.359 --> 00:22:30.559 But doesn't the whole point of the typescript compiler that, 323 00:22:30.680 --> 00:22:33.519 as you you know, you write your typescript code and 324 00:22:33.559 --> 00:22:35.759 then it compiles. It does I was checking it saves 325 00:22:35.759 --> 00:22:37.839 it to job script files, and that's what you want 326 00:22:37.839 --> 00:22:39.680 to build off of, isn't am I crrect? 327 00:22:39.759 --> 00:22:43.319 Yeah? Look, there there are really two ways these days 328 00:22:43.319 --> 00:22:48.119 in which you can run typescript on top of note, 329 00:22:49.359 --> 00:22:53.359 the way that you usually want to do in production 330 00:22:53.519 --> 00:22:56.799 environments is you want to run the Typescript compiler TSC. 331 00:22:58.079 --> 00:23:01.319 It runs, it does all the X, it fails if 332 00:23:01.359 --> 00:23:05.000 it identifies an error, but if everything is fine, it 333 00:23:05.319 --> 00:23:08.720 general like you said, it generates JavaScript files from the 334 00:23:08.759 --> 00:23:11.720 typescript files. So for every dot TS file you get 335 00:23:11.720 --> 00:23:16.400 a dot js file, and in that JS it's basically 336 00:23:16.519 --> 00:23:21.880 just essentially looked mostly like stripped out the type information. 337 00:23:22.559 --> 00:23:26.039 And then ideally you would just deploy those JS files 338 00:23:26.079 --> 00:23:29.559 and you don't deploy the TS files. But as I explained, 339 00:23:29.599 --> 00:23:35.279 the way that our CICD pipeline was built, because it 340 00:23:35.359 --> 00:23:39.359 was originally done before TSC, nobody thought about about that. 341 00:23:39.799 --> 00:23:42.200 The way that it worked was that it actually did 342 00:23:42.240 --> 00:23:47.559 a Git pull directly to the production pod that it 343 00:23:47.640 --> 00:23:51.839 was building, and then ran a quote unquote build on it, 344 00:23:51.880 --> 00:23:57.920 which effectively did very little in the pre TSC scenario. 345 00:23:58.519 --> 00:24:04.039 In the TSC scenario, that build actually runs the TSC compiler. 346 00:24:04.599 --> 00:24:13.000 So building the production pod required having TSC on that pod, 347 00:24:13.359 --> 00:24:18.480 so again not ideal. A better solution would be to 348 00:24:18.519 --> 00:24:27.640 fix the CICD pipeline, but that's how it was built 349 00:24:27.640 --> 00:24:29.880 when it was built, and I didn't want to mess 350 00:24:29.920 --> 00:24:37.079 about with the CICD job and building new one or whatever. 351 00:24:38.119 --> 00:24:41.799 As I said, I don't consider myself a dev's off person, 352 00:24:41.920 --> 00:24:45.680 and if I can avoid doing that, and I prefer to. 353 00:24:46.160 --> 00:24:49.359 By the way, these days, there's a different you can 354 00:24:49.480 --> 00:24:53.920 there's a different way for running typescript on top of Node. 355 00:24:56.079 --> 00:24:59.599 Actually there's a couple of ways. So first of all, 356 00:24:59.599 --> 00:25:05.160 there's this project called tsnode which literally wraps Node and 357 00:25:05.799 --> 00:25:12.119 adds TSC some support for typescript files into Node by 358 00:25:12.160 --> 00:25:16.119 effectively running TSC when it loads a file when files 359 00:25:16.119 --> 00:25:20.160 are loaded into Node, so you can use tsnode to 360 00:25:20.400 --> 00:25:25.319 run the typescript files directly on note without having to 361 00:25:25.400 --> 00:25:28.359 use TSC first to build the jobscript project out of it. 362 00:25:28.920 --> 00:25:31.759 But obviously this is not something you really want in 363 00:25:31.799 --> 00:25:35.680 production environments because all that thing adds a lot of 364 00:25:35.759 --> 00:25:40.400 overhead when the Node process starts, and why pay for 365 00:25:40.480 --> 00:25:48.079 that overhead. What the Node team has recently done is 366 00:25:48.119 --> 00:25:54.640 they've actually added a new command line switch, which kind 367 00:25:54.640 --> 00:25:59.440 of quote unquote gives Node TS support. The way that 368 00:25:59.519 --> 00:26:03.799 they do though, is not by running TSC, is by 369 00:26:03.920 --> 00:26:08.519 stripping out the type information. So think about like it's 370 00:26:08.640 --> 00:26:13.039 it's overwriting all the type definition with spaces, so it's 371 00:26:13.119 --> 00:26:18.240 kind of evaporating the type information out of the out 372 00:26:18.319 --> 00:26:21.160 of the TS files and then what you're left with 373 00:26:21.319 --> 00:26:24.119 is just JavaScript and it runs that, and it can 374 00:26:24.160 --> 00:26:28.720 do that fairly quickly. But on the conversely, it doesn't 375 00:26:28.720 --> 00:26:32.559 actually do any type checking. It just so they expect 376 00:26:32.559 --> 00:26:35.039 you to do the type checking beforehand, but they say 377 00:26:35.079 --> 00:26:38.559 you can still run the TS files directly and you 378 00:26:38.720 --> 00:26:43.440 hardly pay any over any overhead costs for that. Is 379 00:26:43.440 --> 00:26:44.000 that clear? 380 00:26:44.279 --> 00:26:46.400 Yes, sir, good. 381 00:26:46.759 --> 00:26:52.400 But again this is variatively new, relatively recent, and when 382 00:26:52.440 --> 00:26:56.200 I worked on that project, I didn't use it, so 383 00:26:56.319 --> 00:27:00.440 I I really needed to compile the TS file into 384 00:27:00.519 --> 00:27:05.400 JS files. So as I said, I installed TS, I 385 00:27:05.440 --> 00:27:07.759 initialized it, but I put it as part of the 386 00:27:07.799 --> 00:27:11.839 pro dependency, not a dev dependency because of the way 387 00:27:11.839 --> 00:27:15.799 in which our CICD pipeline is built. When you install 388 00:27:16.119 --> 00:27:20.599 an initialized when you initialize typescript, actually it generates a 389 00:27:20.640 --> 00:27:24.240 TS config file or TS configured dot json file to 390 00:27:24.319 --> 00:27:29.160 be precise, at the root of your folder of your project. Sorry. 391 00:27:29.599 --> 00:27:33.960 In fact, that's how TSC knows where the root of 392 00:27:34.000 --> 00:27:37.039 your project is. It assumes that where that file is 393 00:27:37.119 --> 00:27:42.440 located is the root of your project, and that ts 394 00:27:42.480 --> 00:27:46.599 configured dot json files is a JSON file obviously of 395 00:27:46.720 --> 00:27:52.680 configuration data for TSC telling it how to work how 396 00:27:52.720 --> 00:27:57.759 to process your project. For example, you can tell it 397 00:27:58.279 --> 00:28:05.559 which folders to include or exclude from its compilation. In 398 00:28:05.640 --> 00:28:10.079 our case, all the source files except for the root 399 00:28:10.200 --> 00:28:14.480 index file resided in an src folder, and all the 400 00:28:14.559 --> 00:28:17.839 test files the unit test files, and also some of 401 00:28:18.119 --> 00:28:22.119