WEBVTT 00:00:12.120 --> 00:00:15.680 Scott: Welcome to the Bikeshed Podcast, where we talk about all things software engineering, 00:00:16.230 --> 00:00:19.600 Scott: our latest opinions, and all the mistakes we have made in retrospect. 00:00:20.860 --> 00:00:26.040 Scott: I'm your co-host, a walking ventriloquist, but no dummy, Scott Kaye. 00:00:26.470 --> 00:00:28.360 Scott: And alongside with me are my co-hosts. 00:00:28.780 --> 00:00:32.300 Scott: He built an app to manage his finances, but still went over budget. 00:00:33.400 --> 00:00:41.160 Scott: Matt Hamlin and the king of calm, the rattlesnake of takes, Dillon, spicy, take, Curry. 00:00:42.760 --> 00:00:44.720 Scott: Fellas, what's on our agenda today? 00:00:45.760 --> 00:00:47.140 Dillon: The one version rule, Scott. 00:00:48.620 --> 00:00:49.520 Dillon: Take it away, Matt. 00:00:51.540 --> 00:00:51.860 Matt: But Dillon, 00:00:52.060 --> 00:00:52.960 Matt: what is the one version rule? 00:00:53.720 --> 00:00:55.620 Matt: No, yeah, hopefully we get to talk about that. 00:00:55.680 --> 00:00:58.680 Matt: I think today we're generally talking about dependency 00:00:59.000 --> 00:01:01.120 Matt: management for maybe front end projects. 00:01:01.840 --> 00:01:03.000 Matt: Maybe we branch out of that. 00:01:03.200 --> 00:01:05.519 Matt: But yeah, the one version role is something 00:01:05.760 --> 00:01:09.900 Matt: that we had adopted at Wayfair related to dependency management. 00:01:10.070 --> 00:01:11.440 Matt: So we want to talk a little bit about it. 00:01:12.120 --> 00:01:14.400 Matt: And this is kind of hot on the tails of our monorepo madness 00:01:14.720 --> 00:01:18.580 Matt: episode, which we got some feedback from the community 00:01:18.820 --> 00:01:20.320 Matt: about what about dependencies? 00:01:20.660 --> 00:01:21.840 Matt: Or how do you manage dependencies? 00:01:23.580 --> 00:01:26.580 Matt: And so I figured it'd be good for us to dig into that. 00:01:26.830 --> 00:01:28.440 Matt: I think there's a lot of interesting things to dig in here. 00:01:28.990 --> 00:01:31.500 Matt: So obviously, like how we managed dependencies 00:01:31.710 --> 00:01:32.780 Matt: in monorepos at Wayfair, 00:01:32.880 --> 00:01:35.560 Matt: and then maybe how we've moved to manage dependencies 00:01:35.770 --> 00:01:36.540 Matt: at other companies. 00:01:37.400 --> 00:01:39.480 Matt: I think I can talk a little bit about HubSpot's 00:01:39.580 --> 00:01:42.200 Matt: dependency management strategy, which is pretty unique. 00:01:42.550 --> 00:01:45.560 Matt: I haven't seen it used anywhere else, actually. 00:01:45.960 --> 00:01:47.840 Matt: So I think it'll be interesting to dig into that. 00:01:49.380 --> 00:01:50.300 Matt: Let's see, where should we start? 00:01:52.120 --> 00:01:55.480 Matt: I guess, like, on the topic of-- 00:01:56.000 --> 00:01:58.020 Matt: I guess maybe reminding you a little bit-- 00:01:58.080 --> 00:02:00.620 Matt: dependency management, for those that don't know, 00:02:00.880 --> 00:02:02.540 Matt: but I feel like most of our audience does know, 00:02:02.620 --> 00:02:06.300 Matt: is that in the front end space, we 00:02:06.540 --> 00:02:09.479 Matt: use a lot of NPM modules, node package manager modules. 00:02:11.460 --> 00:02:13.900 Matt: Those are just like libraries and bits of code 00:02:14.020 --> 00:02:15.320 Matt: that people distribute across NPM. 00:02:15.480 --> 00:02:18.260 Matt: And then you pull it into your project 00:02:18.560 --> 00:02:19.760 Matt: by declaring a dependency on it. 00:02:20.780 --> 00:02:22.620 Matt: And people can update that library over time 00:02:23.120 --> 00:02:24.360 Matt: and publish new versions. 00:02:24.820 --> 00:02:27.240 Matt: And you have to sort of, by default, 00:02:27.940 --> 00:02:30.200 Matt: you have to go in and sort of make an update to your project 00:02:30.260 --> 00:02:31.120 Matt: to pull in that new version. 00:02:34.000 --> 00:02:36.480 Matt: So dependency management is sort of like the work that 00:02:36.500 --> 00:02:38.820 Matt: is required to manage your dependencies, 00:02:39.120 --> 00:02:42.260 Matt: like pull in new versions, manage breaking changes 00:02:42.360 --> 00:02:43.980 Matt: in those libraries if there are any-- 00:02:46.900 --> 00:02:47.720 Matt: keep track of-- 00:02:48.160 --> 00:02:50.740 Matt: maybe there's a change that wasn't marked as a breaking change 00:02:50.760 --> 00:02:51.920 Matt: library, but it broke things for you. 00:02:51.990 --> 00:02:54.940 Matt: And so you need to manage how you deal with that in your project. 00:02:56.460 --> 00:02:56.900 Matt: Yeah, I don't know. 00:02:58.560 --> 00:03:01.900 Matt: Maybe I'm sort of just saying the obvious. 00:03:02.260 --> 00:03:03.780 Matt: But that's what we're covering today. 00:03:05.840 --> 00:03:06.940 Matt: Where do you guys want to start? 00:03:07.560 --> 00:03:09.540 Matt: Should we start with the one version rule? 00:03:09.540 --> 00:03:13.020 Matt: I feel like that's maybe an interesting topic to dig into. 00:03:13.320 --> 00:03:15.720 Matt: But are there some more basic aspects of this 00:03:15.750 --> 00:03:16.360 Matt: that we should cover? 00:03:17.640 --> 00:03:19.700 Dillon: Let's just dig in and see where it takes us. 00:03:20.760 --> 00:03:22.400 Matt: Let's talk about maybe the one version rule. 00:03:23.310 --> 00:03:25.000 Matt: Can you sort of elaborate to our listeners, 00:03:25.360 --> 00:03:30.780 Matt: maybe if you know, the sort of impetus for why we chose 00:03:31.070 --> 00:03:36.040 Matt: or why we decided to sort of reach for the one version rule at Wayfair? 00:03:38.100 --> 00:03:39.400 Dillon: I can kind of give my perspective. 00:03:39.550 --> 00:03:42.260 Dillon: I definitely wasn't a part of all the decisions made 00:03:42.420 --> 00:03:44.180 Dillon: to why we ended up going that route. 00:03:45.360 --> 00:03:50.020 Dillon: I think part of it was a need of we were running into issues 00:03:50.040 --> 00:03:51.880 Dillon: too many teams using different versions of libraries. 00:03:52.980 --> 00:03:58.080 Dillon: It was really hard to reconcile that and take all that code and build an app out of it without 00:03:58.320 --> 00:04:01.740 Dillon: shipping multiple versions of different libraries, which is a waste. 00:04:02.360 --> 00:04:03.560 Dillon: So maybe that's a big part of it. 00:04:04.740 --> 00:04:11.840 Dillon: But also, I think there's an industry shift towards one version rule because everyone 00:04:12.020 --> 00:04:15.040 Dillon: started to notice, hey, we can ship smaller bundles if we're all using the same version. 00:04:15.260 --> 00:04:19.519 Dillon: Also, it just makes the most sense to only use one version of React, for instance. 00:04:20.079 --> 00:04:25.380 Dillon: we shouldn't be shipping 26 versions of react like what are we doing this is stupid 00:04:27.819 --> 00:04:32.820 Matt: yeah for sure and certainly like react is like a good example to look at primarily because it 00:04:33.440 --> 00:04:37.040 Matt: like usually only works like a singleton so like if you have multiple versions of it 00:04:37.560 --> 00:04:42.920 Matt: you're probably going to run into some bugs at runtime um i'm sure most people have probably seen 00:04:42.940 --> 00:04:47.619 Matt: that error like all right make sure you know react and react on versions are the same and like 00:04:47.860 --> 00:04:52.960 Matt: Make sure you're not pulling in multiple different versions of React or react-dom your page. 00:04:53.720 --> 00:04:56.360 Matt: Lean to the hook errors or whatever they were. 00:04:57.920 --> 00:04:59.520 Matt: Yeah, I think more generally, it's like what you're saying. 00:04:59.740 --> 00:05:05.580 Matt: It's like, you don't want to, if you're pulling in a library, whether it's internal or external, into your application, 00:05:06.040 --> 00:05:13.880 Matt: you don't want to pull in multiple different copies of it just to have your customers load 3x the JavaScript they need, for example, if you're pulling it in three times. 00:05:15.700 --> 00:05:27.120 Scott: I think you noted this, but it also would cause all sorts of types of pain when trying to use, say, okay, for example, a library, like something that might be used in multiple places. 00:05:27.880 --> 00:05:32.220 Scott: If you're pulling in all sorts of different versions of that, there might be some conflicts. 00:05:32.510 --> 00:05:34.120 Scott: It would cause all sorts of pain there. 00:05:34.470 --> 00:05:35.480 Scott: That would make it just difficult. 00:05:36.960 --> 00:05:42.160 Scott: This can happen within a dependency as well. 00:05:42.400 --> 00:05:45.760 Scott: if a dependency you're using relies on a different version. 00:05:46.280 --> 00:05:47.780 Scott: I think we've seen this with Storybook. 00:05:49.040 --> 00:05:52.220 Scott: If it internally is using a dependency you have, 00:05:53.240 --> 00:05:55.420 Scott: that's a hard problem to figure out. 00:05:55.440 --> 00:05:56.520 Scott: There are ways around that, 00:05:56.780 --> 00:06:01.660 Scott: but it just kind of gives you a more clear guideline 00:06:02.840 --> 00:06:04.780 Scott: on this is where we're at. 00:06:04.840 --> 00:06:06.860 Scott: We're trying to continuously move forward 00:06:07.920 --> 00:06:10.700 Scott: and we're all working off the same common infrastructure. 00:06:11.400 --> 00:06:22.740 Scott: So when someone goes into a new library or a new application, they have a little bit more common knowledge that the entire team is trying to share and build off of. 00:06:23.430 --> 00:06:31.540 Scott: It allows us to continue to move fast, continue to grow, and for people to have a dedicated understanding that we're moving towards the same common goal. 00:06:32.160 --> 00:06:36.800 Scott: And it doesn't allow an application to get as stale or be like, this is just the way things are. 00:06:36.970 --> 00:06:47.720 Scott: Or it's so difficult to untangle that we don't want to invest the time and just create this epic tech debt that eventually would likely get blown away. 00:06:48.360 --> 00:06:55.180 Scott: Or, you know, cause us to slow down a merge for getting something live. 00:06:55.230 --> 00:07:00.420 Scott: If we have a really tight or stressful deadline for building something. 00:07:00.840 --> 00:07:06.340 Scott: We don't want to let like one ancillary dependency or a series of them make things more difficult. 00:07:06.600 --> 00:07:14.520 Scott: Or we don't want to have an engineer jump from application or library to realize they can't use certain tools that exist. 00:07:14.540 --> 00:07:17.800 Scott: We want to have consistency so people can move fast 00:07:17.800 --> 00:07:18.120 Scott: everywhere. 00:07:19.600 --> 00:07:20.660 Dillon: Say move fast everywhere. 00:07:20.940 --> 00:07:30.040 Dillon: I think there's like a drawback to the one version rule, which is if I'm a library developer or I'm making changes to the application, whatever. 00:07:31.340 --> 00:07:35.640 Dillon: and we're working in a monorepo maybe there's multiple applications and now I want to like 00:07:35.820 --> 00:07:43.180 Dillon: upgrade a specific version of some package that could be like a really big project all of a sudden 00:07:43.360 --> 00:07:49.000 Dillon: right if it's a one if we're using one version rule and all apps are using this package it's no 00:07:49.080 --> 00:07:53.539 Dillon: it's no longer like I'm just updating this package for my app I'm updating it for everybody 00:07:53.620 --> 00:07:56.020 Dillon: basically and maybe that's something we get into 00:07:56.120 --> 00:07:59.780 Dillon: there's like a gradual 00:08:00.060 --> 00:08:02.780 Dillon: upgrade process that's still in a version rule where you can 00:08:03.840 --> 00:08:05.900 Dillon: upgrade one project but that seems to sort of break 00:08:07.619 --> 00:08:09.580 Dillon: the rules of one version rule 00:08:10.340 --> 00:08:11.240 Dillon: in a sense 00:08:12.400 --> 00:08:15.960 Dillon: I've already seen that I want to upgrade from next 14 to 15 00:08:16.060 --> 00:08:18.900 Dillon: and it's become like a project where now I'm 00:08:19.040 --> 00:08:22.159 Dillon: upgrading every app and it's just do I really want to do this 00:08:23.000 --> 00:08:24.140 Dillon: like this is too much for me 00:08:25.380 --> 00:08:26.460 Matt: yeah it's certainly 00:08:26.850 --> 00:08:28.340 Matt: I think and you know it's not 00:08:28.510 --> 00:08:30.320 Matt: not directly coupled to one version of itself 00:08:30.500 --> 00:08:32.340 Matt: but just like general dependency management I think 00:08:32.440 --> 00:08:32.960 Matt: also like 00:08:34.659 --> 00:08:36.400 Matt: managing upgrades especially breaking 00:08:36.580 --> 00:08:37.680 Matt: changes is pretty 00:08:38.680 --> 00:08:40.460 Matt: hefty in the front end ecosystem 00:08:40.840 --> 00:08:42.300 Matt: like there's quite a bit of effort 00:08:42.460 --> 00:08:44.000 Matt: that's required usually 00:08:44.700 --> 00:08:45.620 Matt: to manage those 00:08:46.300 --> 00:08:46.480 Matt: upgrades 00:08:48.360 --> 00:08:50.340 Matt: and I think oftentimes 00:08:50.760 --> 00:08:52.140 Matt: maybe teams are 00:08:54.140 --> 00:09:00.240 Matt: well okay in my experience oftentimes teams aren't jumping at the bit to manage dependency upgrades 00:09:00.960 --> 00:09:04.940 Matt: all that frequently which I think sort of leads to this like negative feedback cycle of like 00:09:05.700 --> 00:09:11.120 Matt: okay you know you don't upgrade from React 18 to React 19 and or you know I don't know maybe 00:09:11.340 --> 00:09:15.520 Matt: maybe a better example you don't upgrade from React 16 to React 17 which was like actually a 00:09:16.070 --> 00:09:21.300 Matt: relatively minor upgrade and now three years later they're on React 19 and you're still on React 16 00:09:21.300 --> 00:09:27.460 Matt: and now the upgrade process is like you know maybe 3x the effort right because it's the breaking 00:09:27.620 --> 00:09:32.300 Matt: changes from you have to like manage like multiple different um sort of phases of breaking changes 00:09:32.990 --> 00:09:37.960 Matt: um and so i think it's often oftentimes you see teams like maybe fall behind on updates 00:09:39.180 --> 00:09:44.080 Matt: and that like sort of leads into this case where it's like okay now you have to like do a lot more 00:09:44.170 --> 00:09:48.160 Matt: effort to update and so then maybe teams are like well it's not really worth the effort i just want 00:09:48.100 --> 00:09:52.560 Matt: keep shipping stuff and so like you keep pushing it off and then and you find yourself five years 00:09:52.700 --> 00:09:57.620 Matt: later and it's like oh they're pretty far behind um like part of me wonders if that's like why 00:09:58.080 --> 00:10:03.600 Matt: many teams choose to do a rewrite instead of uh sort of incremental adoption like it's easier to 00:10:03.610 --> 00:10:09.940 Matt: start from a fresh slate and and and with the like current version of dependencies um but maybe 00:10:10.060 --> 00:10:11.440 Matt: that's like a separate topic that we dig into 00:10:11.440 --> 00:10:14.540 Scott: i think that always comes into like what are teams 00:10:14.560 --> 00:10:23.280 Scott: priorities. We've talked about this, maybe not on the podcast. When you're on a platform team, 00:10:23.970 --> 00:10:30.740 Scott: your priorities of managing dependencies, getting out new features, that's very pivotal to what 00:10:30.740 --> 00:10:35.000 Scott: you're doing. You really want to unlock the latest and greatest. You want to make sure things stay 00:10:35.500 --> 00:10:40.560 Scott: more performant. These are the kinds of features we're getting out of new React versions. And if 00:10:40.500 --> 00:10:49.600 Scott: team's priorities are to like build a new feature and the you know they're not worried about the 00:10:50.080 --> 00:10:54.280 Scott: maybe the larger minutia of how the application works but rather the downstream's effects on how 00:10:54.280 --> 00:11:00.520 Scott: it impacts them so what you're saying matt where you know maybe you end up on react 16 and 19's out 00:11:00.660 --> 00:11:06.279 Scott: and then now there's this stress because oh react 19 actually unlocks this feature that we really 00:11:06.320 --> 00:11:12.040 Scott: really need and teams are more likely so this is the concept i wanted to get to teams are more 00:11:12.300 --> 00:11:18.180 Scott: likely to be willing or be part of an upgrade when it unlocks something for them this goes 00:11:19.420 --> 00:11:26.360 Scott: like double for for almost anything uh basically whether it's a new component in a component 00:11:26.560 --> 00:11:34.060 Scott: library or it's a new way to gain performance teams start to get eager to have this when when 00:11:34.080 --> 00:11:40.480 Scott: they have that pain point uh so basically i'm just bringing up a rule of thumb that i want to speak 00:11:40.510 --> 00:11:48.040 Scott: for everyone but i feel like we found it painful often to do upgrades if they're not easy code mods 00:11:48.340 --> 00:11:53.440 Scott: usually are one way of making it easy but also if teams are getting something they want 00:11:54.360 --> 00:11:58.780 Scott: you're you're more likely to gain traction with those folks i 00:11:58.780 --> 00:12:01.560 Matt: think um i don't necessarily want 00:12:01.560 --> 00:12:07.900 Matt: to derail the current topic, but I think an interesting maybe sort of, I don't know, like 00:12:08.280 --> 00:12:12.480 Matt: sort of an interesting sort of look at here also in terms of dependency management, like 00:12:12.490 --> 00:12:13.520 Matt: we're talking a lot about the pain. 00:12:13.850 --> 00:12:16.820 Matt: I think it might be interesting for me to share a little bit about HubSpot's dependency 00:12:17.140 --> 00:12:23.200 Matt: management sort of lifecycle because it's sort of directly targeted at resolving that 00:12:23.340 --> 00:12:23.420 Matt: pain. 00:12:25.020 --> 00:12:29.300 Matt: At Wayfair, we opted for a monorepo to try to like resolve some of that dependency upgrade 00:12:29.320 --> 00:12:33.800 Matt: pane where it's like okay you release a minor version of library you know either you need to go 00:12:33.980 --> 00:12:39.280 Matt: in and upgrade all your consumer like all the apps that depend on you um to use the new version or 00:12:39.470 --> 00:12:43.800 Matt: tell those teams to do that work for you and like you know hope that it gets prioritized like like 00:12:43.860 --> 00:12:47.320 Matt: what scott was saying in terms of like you got to kind of need like work with those teams to 00:12:47.550 --> 00:12:54.580 Matt: prioritize it um at hubspot we sort of took i wasn't here for it but like from what i've seen 00:12:54.600 --> 00:12:56.620 Matt: And they've sort of taken an interesting path 00:12:56.620 --> 00:12:59.300 Matt: where what we have is an evergreen dependency system, 00:13:00.279 --> 00:13:03.440 Matt: which means that basically on every push to a library, 00:13:04.180 --> 00:13:05.560 Matt: as long as it's not a break and change, 00:13:06.900 --> 00:13:10.180 Matt: all your downstream consumers will automatically pull it down 00:13:10.340 --> 00:13:10.980 Matt: next time they build. 00:13:11.840 --> 00:13:14.520 Matt: And we have internal build tooling that kicks off those builds 00:13:15.220 --> 00:13:15.920 Matt: for those consumers. 00:13:16.940 --> 00:13:18.140 Matt: And then they can sort of deploy. 00:13:18.800 --> 00:13:20.840 Matt: If they're doing continuous deployment, they can deploy right after, 00:13:21.020 --> 00:13:23.880 Matt: or they'll just be deployed next time they go to do a deploy. 00:13:24.520 --> 00:13:27.900 Matt: So effectively, you're using a dependency management service 00:13:28.110 --> 00:13:29.600 Matt: or you're managing dependencies, 00:13:29.860 --> 00:13:31.420 Matt: but you don't really have to think about it. 00:13:31.550 --> 00:13:33.320 Matt: It sort of gets automatically pulled down for you 00:13:33.530 --> 00:13:37.340 Matt: and used anytime you run builds locally or builds. 00:13:37.620 --> 00:13:38.460 Matt: Now, there's trade-offs to that. 00:13:38.550 --> 00:13:39.300 Matt: There are different trade-offs, 00:13:39.350 --> 00:13:41.380 Matt: but I think it's an interesting sort of conceptual model 00:13:41.580 --> 00:13:44.500 Matt: to see, like, oh, for the most part, 00:13:44.780 --> 00:13:47.060 Matt: library upgrades aren't really a thing here. 00:13:49.400 --> 00:13:50.660 Dillon: As soon as you said that, I was like, 00:13:50.900 --> 00:13:51.700 Dillon: that's forced upgrades. 00:13:52.080 --> 00:13:53.200 Dillon: You're going to, like, break my app, 00:13:53.250 --> 00:13:54.180 Dillon: and I'm not going to know why. 00:13:54.820 --> 00:14:00.960 Dillon: because like I pushed a change and then something breaks and I'm thinking oh it's probably my changes 00:14:01.580 --> 00:14:06.300 Dillon: but it could be like these six other libraries that changed so how do how do they deal with 00:14:06.560 --> 00:14:08.260 Dillon: that situation for 00:14:08.260 --> 00:14:12.260 Matt: sure yeah so there's yeah that's like in my mind one of the largest trade-offs of 00:14:12.260 --> 00:14:17.780 Matt: the system what we have like some internal tools that allow you to sort of test a library change 00:14:18.560 --> 00:14:23.660 Matt: across your consumers so that could be we have like library canaries basically you like before 00:14:23.680 --> 00:14:27.780 Matt: you even merge your change on your branch, you can say, I want to canary my change of 00:14:27.880 --> 00:14:31.160 Matt: this library to my dependents or to the things that depend on me. 00:14:31.880 --> 00:14:35.540 Matt: And it'll go out and like deploy, build and deploy those applications 00:14:36.130 --> 00:14:39.480 Matt: at a certain percentage for your library and then report back if there's any major errors, 00:14:40.100 --> 00:14:43.660 Matt: which is basically like, you know, sort of the same canary process that we had in terms of deploying applications. 00:14:46.020 --> 00:14:46.260 Matt: And 00:14:48.020 --> 00:14:50.340 Matt: so there's that system. We also have like a whole 00:14:50.940 --> 00:14:53.000 Matt: sort of way to kick off builds 00:14:53.160 --> 00:14:54.540 Matt: that don't actually get deployed, 00:14:54.880 --> 00:14:56.080 Matt: but just build your library 00:14:56.620 --> 00:14:59.240 Matt: or build your dependents with your changes 00:15:00.980 --> 00:15:02.140 Matt: and just see if the builds pass. 00:15:02.480 --> 00:15:03.720 Matt: Basically, it gives you a report of, 00:15:03.780 --> 00:15:04.600 Matt: do the builds pass? 00:15:04.980 --> 00:15:05.100 Matt: Okay. 00:15:05.780 --> 00:15:06.840 Matt: Do their tests pass? 00:15:07.200 --> 00:15:07.720 Matt: Things like that. 00:15:09.140 --> 00:15:11.000 Matt: And so, yeah, 00:15:11.320 --> 00:15:12.560 Matt: we built a lot of internal tooling 00:15:12.720 --> 00:15:14.700 Matt: to try to provide as much feedback 00:15:14.820 --> 00:15:15.900 Matt: and insight as possible 00:15:16.040 --> 00:15:17.560 Matt: and to, does this library change 00:15:18.020 --> 00:15:19.240 Matt: cause this other issue? 00:15:20.280 --> 00:15:20.920 Scott: That's really interesting. 00:15:21.180 --> 00:15:24.020 Scott: I'm curious, like, I want to hear a little more about that. 00:15:24.100 --> 00:15:31.780 Scott: Like, can, can you see a visual build, like some sort of like staging with, with that 00:15:31.780 --> 00:15:32.360 Scott: in that process? 00:15:32.720 --> 00:15:39.780 Scott: So basically you merge in your changes, um, and it has like this canary version of other 00:15:39.960 --> 00:15:40.180 Scott: upgrades. 00:15:41.080 --> 00:15:42.640 Scott: Can you go like test that manually? 00:15:43.320 --> 00:15:43.660 Scott: Look at that. 00:15:44.340 --> 00:15:45.340 Matt: Can you rephrase that question? 00:15:45.580 --> 00:15:50.440 Matt: Like, are you asking, like, can you verify those changes before being released to prod 00:15:50.490 --> 00:15:52.180 Matt: or, like, in your consumers? 00:15:53.660 --> 00:15:56.760 Scott: I guess what I'm asking is it builds it, right? 00:15:57.000 --> 00:15:58.920 Scott: And that's, like, some CI, CD stuff. 00:15:59.260 --> 00:15:59.380 Scott: Great. 00:15:59.740 --> 00:16:03.960 Scott: Can you go then use that application that got built somewhere in, like, a staging environment? 00:16:05.400 --> 00:16:07.360 Matt: Yeah, we have, like, preview deploys. 00:16:07.750 --> 00:16:11.680 Matt: So you could go in and, like, kick off a preview deploy for an application 00:16:12.090 --> 00:16:14.420 Matt: or, like, open a PR for it to, like, kick off a preview deploy. 00:16:14.700 --> 00:16:21.820 Matt: And then be able to visit and see those changes behind, in our case, we're using cookies, sort of behind a cookie. 00:16:21.880 --> 00:16:25.280 Matt: In the same way that we sort of did some preview routing at Wayfair also. 00:16:26.240 --> 00:16:27.140 Matt: Kind of similar setup. 00:16:28.440 --> 00:16:29.860 Matt: So yeah, you can preview those changes. 00:16:30.680 --> 00:16:36.160 Scott: So you can kind of look at, even if all the CICD passes, you can still kind of look at the differences. 00:16:37.160 --> 00:16:38.560 Scott: I would assume they're not major. 00:16:39.160 --> 00:16:43.380 Scott: I guess it depends on how complex and how big of an upgrade. 00:16:44.380 --> 00:16:48.580 Scott: Would there be major breaking change upgrades that might be going, 00:16:49.020 --> 00:16:50.500 Scott: going out while you're doing something like that? 00:16:52.840 --> 00:16:54.640 Matt: We don't usually do major changes, 00:16:54.920 --> 00:16:55.780 Matt: major version upgrades 00:16:55.780 --> 00:16:56.580 Scott: ok 00:16:56.580 --> 00:16:57.340 Matt: their internal libraries. 00:16:57.640 --> 00:16:59.060 Matt: So like a lot of our libraries are, 00:16:59.360 --> 00:17:01.800 Matt: and we have a different versioning scheme than Sember, 00:17:01.940 --> 00:17:02.560 Matt: which is interesting, 00:17:02.720 --> 00:17:06.480 Matt: but it's basically we have like a major version and then a build number. 00:17:07.140 --> 00:17:11.500 Matt: So sometimes you'll see like a version number that's like 1.1234, 00:17:11.560 --> 00:17:20.459 Matt: for example, which means it's the 1,234th build of the 1.x version line. 00:17:21.120 --> 00:17:21.380 Matt: Cool. 00:17:22.100 --> 00:17:25.360 Matt: And so you can bump that 1 to 2, 00:17:25.620 --> 00:17:28.220 Matt: but most of our dependencies are still in the 1.x range 00:17:29.930 --> 00:17:31.540 Matt: just because breaking changes usually don't happen. 00:17:32.020 --> 00:17:35.680 Matt: Instead, what happens usually is that teams will just go 00:17:35.690 --> 00:17:37.860 Matt: and build a new version of the library, like a separate name, 00:17:38.230 --> 00:17:40.300 Matt: and then do a migration over to that. 00:17:41.420 --> 00:17:43.280 Matt: Also like an interesting sort of aspect is like, 00:17:44.800 --> 00:17:46.840 Matt: you guys were talking about like, sort of like, oh, like, you know, 00:17:46.940 --> 00:17:47.660 Matt: like how do you know, 00:17:47.820 --> 00:17:49.440 Matt: like what changes are included when you deploy or whatever. 00:17:49.600 --> 00:17:52.020 Matt: It's like, when we go to see our builds for specific applications, 00:17:52.220 --> 00:17:56.040 Matt: you can sort of see like, like each build will say like, okay, 00:17:56.220 --> 00:17:58.160 Matt: this was built because of, you know, 00:17:58.360 --> 00:18:00.640 Matt: certain dependencies changed or code was pushed or whatever. 00:18:00.820 --> 00:18:03.520 Matt: And so, and it lists out like 13 dependencies changed. 00:18:03.580 --> 00:18:05.200 Matt: You can click in and see like, what are those dependencies? 00:18:05.500 --> 00:18:09.180 Matt: What did they upgrade from to, to, to help you like identify like, okay, 00:18:09.260 --> 00:18:14.700 Matt: I'm releasing a change that had a version bump of our internal component library, for example. 00:18:15.960 --> 00:18:17.480 Matt: And so I can kind of see when that happens. 00:18:19.260 --> 00:18:20.080 Scott: Yeah, it seems really cool. 00:18:20.980 --> 00:18:21.660 Scott: It seems really robust. 00:18:22.740 --> 00:18:27.140 Dillon: Matt's spilling all of HubSpot's secrets about how they do management. 00:18:28.660 --> 00:18:28.920 Matt: I mean, 00:18:30.200 --> 00:18:31.200 Matt: yeah, it's interesting. 00:18:31.340 --> 00:18:35.700 Matt: I've talked to a few other people that have worked at Wayfair and work at HubSpot now. 00:18:35.740 --> 00:18:39.800 Matt: And I think the thing that HubSpot maybe, 00:18:40.150 --> 00:18:42.000 Matt: it wasn't very clear to a lot of people internally 00:18:42.170 --> 00:18:43.360 Matt: maybe at HubSpot that I talked to, 00:18:43.480 --> 00:18:45.540 Matt: but the trade-off that was made 00:18:45.680 --> 00:18:46.740 Matt: when choosing Evergreen Dependencies 00:18:46.940 --> 00:18:50.640 Matt: is that now it's very difficult to reproduce a build. 00:18:53.320 --> 00:18:54.880 Matt: Because essentially every time you do a build, 00:18:54.930 --> 00:18:55.660 Matt: you're pulling in the latest. 00:18:55.880 --> 00:18:57.940 Matt: I mean, there's a flag locally that says 00:18:58.120 --> 00:19:00.220 Matt: you want to update your dependencies when you do a build. 00:19:00.720 --> 00:19:02.220 Matt: And that doesn't default to true currently, 00:19:02.620 --> 00:19:04.180 Matt: but we've talked about maybe changing that default. 00:19:04.620 --> 00:19:05.520 Matt: So it always pulls in the latest. 00:19:07.380 --> 00:19:08.580 Matt: but when you do that 00:19:08.920 --> 00:19:10.680 Matt: it's very hard to reproduce a family build in Blazar 00:19:10.980 --> 00:19:12.860 Matt: because Blazar is our CI system 00:19:13.100 --> 00:19:13.740 Matt: that does builds 00:19:15.220 --> 00:19:16.960 Matt: and it's very difficult to reproduce 00:19:17.020 --> 00:19:18.000 Matt: that because you don't really know 00:19:18.620 --> 00:19:20.280 Matt: what versions you need to pin yourself to 00:19:20.920 --> 00:19:22.840 Matt: and if you can pin those versions 00:19:23.220 --> 00:19:23.720 Matt: locally anymore 00:19:25.040 --> 00:19:26.300 Matt: so that's an interesting tradeoff for it 00:19:26.580 --> 00:19:28.700 Matt: build reproducibility which is something I think 00:19:28.700 --> 00:19:29.880 Matt: we valued a lot at Wayfair 00:19:31.279 --> 00:19:32.460 Matt: we want to be able to 00:19:33.080 --> 00:19:34.259 Matt: roll back and say 00:19:34.280 --> 00:19:35.540 Matt: like, yep, we can reproduce exactly 00:19:35.720 --> 00:19:37.120 Matt: with the specific versions that we wanted. 00:19:38.460 --> 00:19:39.500 Matt: That was an interesting trade-off. 00:19:39.540 --> 00:19:42.140 Matt: I think it wasn't very clear internally based on our docs 00:19:42.340 --> 00:19:44.160 Matt: that a lot of people maybe realized 00:19:44.280 --> 00:19:45.300 Matt: that that was a trade-off that we made. 00:19:47.640 --> 00:19:49.300 Scott: So one of the things we talked about 00:19:51.000 --> 00:19:53.520 Scott: was basically avoiding breaking changes, 00:19:53.820 --> 00:19:55.640 Scott: or I guess trying to avoid breaking changes. 00:19:56.300 --> 00:19:58.460 Scott: It's really interesting, because I think at Wayfair 00:19:58.520 --> 00:20:00.520 Scott: we had a lot of conversation about this, 00:20:01.220 --> 00:20:04.240 Scott: and we kind of started to land toward a camp 00:20:04.260 --> 00:20:12.720 Scott: of like let's try not to release breaking changes unless we really need to um and i've in my limited 00:20:12.940 --> 00:20:19.400 Scott: time i feel like here it is similar where we try not to break things i mean it's it's more robust 00:20:19.620 --> 00:20:24.780 Scott: here where it's like if they do break stuff there's code mods if they do build something new there's 00:20:24.820 --> 00:20:32.000 Scott: code mods and they get you like a good 90 to 95 percent of the way there maybe even more uh so 00:20:32.020 --> 00:20:49.640 Scott: So there's basically, we put a lot of stock into making it easy to consume these things and build developer tools, which I wish at wayfair towards the end. 00:20:49.640 --> 00:20:53.060 Scott: We had more stock in that, I guess, essentially. 00:20:54.260 --> 00:21:01.940 Scott: However, we were leaning towards, this is no like one path here, but should you have libraries 00:21:02.080 --> 00:21:03.920 Scott: breaking changes and how often should that occur? 00:21:05.660 --> 00:21:08.800 Scott: Like that's up, it's solely up to the developer, the product. 00:21:09.840 --> 00:21:15.640 Scott: But I feel like I'm seeing more, hey, let's try to avoid that scenario the best we can. 00:21:15.780 --> 00:21:21.800 Scott: How can we create something new, both at this job and kind of since we've had that consensus, 00:21:22.020 --> 00:21:24.140 Scott: maybe about two years ago now. 00:21:26.120 --> 00:21:27.700 Matt: Yeah, it's definitely, yeah, 00:21:28.010 --> 00:21:28.960 Matt: I think I've seen the same trend 00:21:29.070 --> 00:21:31.780 Matt: where it's like at companies that do, 00:21:32.680 --> 00:21:33.860 Matt: like do dependency management, 00:21:34.080 --> 00:21:35.940 Matt: kind of the way that we've seen it done. 00:21:36.100 --> 00:21:38.280 Matt: It's like, I think a lot of the pressure is around, 00:21:38.450 --> 00:21:40.240 Matt: like don't do a breaking change, 00:21:40.860 --> 00:21:42.280 Matt: but like maybe ironically, 00:21:42.520 --> 00:21:43.480 Matt: like the open source ecosystem 00:21:43.660 --> 00:21:47.440 Matt: is maybe not as bought into that maybe or something. 00:21:47.470 --> 00:21:47.780 Matt: I don't know. 00:21:47.860 --> 00:21:49.760 Matt: It just feels like the open source ecosystem 00:21:49.940 --> 00:21:51.600 Matt: is like major versions exist for a reason. 00:21:51.840 --> 00:21:53.360 Matt: Let's just keep leaning in and using them. 00:21:55.120 --> 00:21:56.340 Matt: But yeah, I don't know. 00:21:56.500 --> 00:22:05.740 Matt: It's interesting to me that that doesn't seem to be a shared belief or something outside of large companies. 00:22:06.400 --> 00:22:08.800 Scott: They call it opt-in adoption, essentially. 00:22:09.550 --> 00:22:18.200 Scott: And maybe, and I don't want to derail much more than this, but maybe the problem with that is there's still the case of that 80-20 rule where 20% never adopts. 00:22:19.659 --> 00:22:25.500 Scott: if you incur a breaking change you're going to have to feel the pain and you're going to have 00:22:25.540 --> 00:22:30.600 Scott: to get that done so maybe there is something to be said about that but also it's a lot easier when 00:22:30.800 --> 00:22:34.600 Scott: you build an open source thing to say well if you want it you're going to have to upgrade 00:22:35.280 --> 00:22:39.340 Scott: like and you're not going to have to feel that pain or be a consumer of that pain 00:22:41.220 --> 00:22:45.120 Matt: previously we talked a little bit about peer deps and like direct deps i think that's 00:22:45.140 --> 00:22:51.380 Matt: an interesting thing to dig into like we at Wayfair we heavily leaned into using peer dependencies for 00:22:51.800 --> 00:22:58.900 Matt: internal library sort of relationships so like if you had a library like say library a and 00:22:59.360 --> 00:23:04.320 Matt: and it needed some feature from library b it would instead of declaring on a direct dependency so just 00:23:04.500 --> 00:23:09.920 Matt: like in packages on dependency on library b it would be a peer dependency on library b so it'd 00:23:09.880 --> 00:23:17.900 Matt: up to the consumer of your library to provide library b when it's using library a um it's 00:23:18.040 --> 00:23:20.940 Matt: interesting you know i think there's like some trade-offs with that it's like you're sort of like 00:23:21.880 --> 00:23:27.380 Matt: you're saying okay like uh you know that my consumer needs to know what i use and depend on 00:23:27.620 --> 00:23:33.440 Matt: sort of like leak my implementation a little bit in a sense but but i think the the benefit that 00:23:33.440 --> 00:23:39.840 Matt: you get out of using peer deps is that it lets the consumer to decide what version they want to 00:23:39.860 --> 00:23:45.600 Matt: fix patch for example they don't they don't have to wait for library a to make some change to 00:23:45.600 --> 00:23:46.000 Matt: you 00:23:46.000 --> 00:23:46.260 Matt: know pull 00:23:46.260 --> 00:23:51.720 Matt: that in that new version dependency into its dependencies um and then consume it they can 00:23:51.720 --> 00:23:58.500 Matt: just immediately upgrade library b and sort of get the benefit out of that fix um but i think also 00:23:58.680 --> 00:24:03.760 Matt: like you know trade-offs with peer dependencies that now you're sort of trying to satisfy pure 00:24:03.820 --> 00:24:08.960 Matt: dependencies in a world where you have like a very tightly i don't know tight like a lot of 00:24:08.820 --> 00:24:12.340 Matt: relationships across your dependency graph can be difficult, 00:24:12.500 --> 00:24:12.600 Matt: right? 00:24:12.860 --> 00:24:14.720 Matt: Because you can have library C that depends on library B 00:24:15.360 --> 00:24:18.820 Matt: at a different semiver major than what library A did. 00:24:19.260 --> 00:24:20.960 Matt: And so now the consumer of library A and C 00:24:21.740 --> 00:24:24.420 Matt: needs to make a choice of which version of B do they pull in. 00:24:26.500 --> 00:24:27.060 Matt: Yeah, I don't know. 00:24:27.100 --> 00:24:28.680 Matt: It's an interesting trade-off. 00:24:28.760 --> 00:24:29.720 Matt: Whereas with direct dependencies, 00:24:30.980 --> 00:24:33.660 Matt: you run the risk of now pulling in separate copies 00:24:34.140 --> 00:24:34.680 Matt: of the same library. 00:24:34.820 --> 00:24:36.880 Matt: And then you're kind of at the whims of how those copies are 00:24:36.920 --> 00:24:38.020 Matt: being resolved during your build. 00:24:38.940 --> 00:24:40.860 Matt: or during local development or whatnot. 00:24:41.200 --> 00:24:43.440 Matt: We saw some issues at Wayfair with PMPM resolutions 00:24:43.860 --> 00:24:44.980 Matt: and multiple copies. 00:24:47.460 --> 00:24:50.860 Dillon: Matt's going to add an Excalidraw to the show notes 00:24:51.220 --> 00:24:53.240 Dillon: to explain the relationship of those 00:24:53.240 --> 00:24:53.540 Matt: ok! 00:24:53.780 --> 00:24:56.200 Dillon: because I'm pretty sure at some point. 00:24:56.640 --> 00:24:58.660 Scott: I want to talk a little bit about the setup 00:24:59.100 --> 00:25:01.140 Scott: of the one version rule that we used 00:25:01.380 --> 00:25:05.340 Scott: and basically how our monorepo looked for this example. 00:25:06.200 --> 00:25:08.460 Scott: Because at Airbnb, we do something a little internal. 00:25:08.540 --> 00:25:12.180 Scott: and different, which is kind of cool, maybe unnecessary. 00:25:12.810 --> 00:25:17.640 Scott: But essentially, Armano repo Wayfair had a root, 00:25:17.940 --> 00:25:20.280 Scott: or I guess global root package.json 00:25:20.840 --> 00:25:23.460 Scott: that kind of declared those dependencies 00:25:24.160 --> 00:25:25.340 Scott: and what version we used. 00:25:25.860 --> 00:25:27.980 Scott: And consuming libraries and applications 00:25:28.540 --> 00:25:32.140 Scott: would just workspace star essentially what was there. 00:25:33.600 --> 00:25:35.159 Scott: So they were just pulling in the version 00:25:35.700 --> 00:25:38.640 Scott: that that top level gave them, 00:25:39.380 --> 00:25:41.180 Scott: which is essentially the same at Airbnb, 00:25:41.620 --> 00:25:42.880 Scott: but we do something interesting 00:25:43.120 --> 00:25:45.920 Scott: where our applications and libraries 00:25:46.180 --> 00:25:48.100 Scott: don't have package.jsons. 00:25:48.980 --> 00:25:50.460 Scott: They actually use something internal 00:25:50.700 --> 00:25:52.060 Scott: that's like a project.json, 00:25:52.620 --> 00:25:56.060 Scott: which allows them to just enable dependencies 00:25:57.020 --> 00:25:58.380 Scott: by turning them on or off. 00:25:59.100 --> 00:26:01.800 Scott: And we actually don't use peer deps here. 00:26:02.480 --> 00:26:13.800 Scott: We do use dev devs and regular dependencies, but there's some internal concepts of like using what is a public dependency versus an internal dependency. 00:26:15.420 --> 00:26:20.100 Scott: So there's other concepts that are added into this that kind of make it a little different. 00:26:20.800 --> 00:26:28.940 Scott: But it enforces us to use the right version in a different way where it's just saying, okay, hey, use this dependency. 00:26:29.900 --> 00:26:32.580 Scott: you don't have the option to even set a dependency. 00:26:33.740 --> 00:26:36.100 Scott: Whereas in the structure we just described, 00:26:36.400 --> 00:26:38.540 Scott: a more common maybe open source structure 00:26:38.680 --> 00:26:40.520 Scott: that Wayfair would use is just say, 00:26:40.800 --> 00:26:41.980 Scott: okay, just use the root one. 00:26:42.340 --> 00:26:45.160 Scott: And we would create a CICD check that's like, 00:26:45.180 --> 00:26:46.460 Scott: hey, you had to use the root one. 00:26:46.740 --> 00:26:48.420 Scott: We wouldn't allow you to pass pipelines 00:26:49.720 --> 00:26:51.040 Scott: unless that were the case. 00:26:51.500 --> 00:26:53.240 Scott: So just an interesting mechanism 00:26:53.500 --> 00:26:55.880 Scott: that we don't really give folks the option 00:26:55.960 --> 00:26:57.140 Scott: to pull in a different version. 00:26:58.800 --> 00:27:13.820 Matt: I'm really curious, Scott, how you, in that ecosystem, like within your monorepo, how do you have a, like, you know, let's say, maybe you can think of better names, but you have two internal libraries and one depends on the other. 00:27:14.000 --> 00:27:15.980 Matt: How do you declare that dependency in your setup? 00:27:18.060 --> 00:27:19.720 Matt: Scott's shaking his head like he doesn't understand the question. 00:27:19.720 --> 00:27:20.280 Scott: That's a great question. 00:27:20.940 --> 00:27:22.380 Scott: No, I understand the question. 00:27:23.080 --> 00:27:24.020 Scott: I don't know the answer. 00:27:24.860 --> 00:27:25.820 Scott: It's just a good question. 00:27:27.000 --> 00:27:28.260 Scott: I don't yet know that answer. 00:27:29.360 --> 00:27:30.280 Scott: so it's a 00:27:30.280 --> 00:27:30.880 Matt: really good question 00:27:32.200 --> 00:27:34.260 Matt: yeah because like I can totally understand your setup 00:27:34.940 --> 00:27:37.060 Matt: if for external dependencies making sense 00:27:37.210 --> 00:27:40.160 Matt: like you as I understand it and correct me if I'm wrong 00:27:40.580 --> 00:27:43.360 Matt: at the root of your monorepo you have a package 00:27:43.500 --> 00:27:46.320 Matt: JSON and it says you know pull in a 00:27:46.380 --> 00:27:49.040 Matt: dependency on React version 19.10 00:27:50.420 --> 00:27:52.200 Matt: and then you have a number of 00:27:52.380 --> 00:27:55.120 Matt: different workspaces or something similar to workspaces in your 00:27:55.380 --> 00:27:58.420 Matt: repo that have project.jsons that say 00:27:58.440 --> 00:27:59.540 Matt: I use React. 00:28:00.480 --> 00:28:02.520 Matt: Just list React as a dependency, 00:28:02.700 --> 00:28:04.920 Matt: and it's just going to resolve that React 19.1, 00:28:05.020 --> 00:28:05.860 Matt: I assume, at the root. 00:28:07.280 --> 00:28:09.840 Matt: Yeah, I'm curious how it handles internal dependencies 00:28:10.080 --> 00:28:13.360 Matt: between libraries, if that's even a thing in your code base. 00:28:14.620 --> 00:28:17.760 Scott: Okay, between libraries that are... 00:28:18.300 --> 00:28:19.880 Matt: Within the same monoregmo, yeah. 00:28:21.140 --> 00:28:22.680 Scott: Yeah, that's a really good question. 00:28:23.440 --> 00:28:26.160 Scott: There's an internal dependencies list, 00:28:26.500 --> 00:28:28.400 Scott: but... 00:28:28.420 --> 00:28:29.160 Matt: So if it's 00:28:29.160 --> 00:28:30.940 Scott: the same concept, you just are 00:28:30.940 --> 00:28:31.960 Scott: able to turn it on 00:28:31.960 --> 00:28:32.340 Scott: or not. 00:28:33.000 --> 00:28:33.220 Matt: Okay. 00:28:33.680 --> 00:28:43.440 Matt: So you might create a new library in your monorepo, say my new lib, and you maybe need to add it to your root package JSON as a dependency, even though it's an internal dependency. 00:28:43.880 --> 00:28:44.560 Matt: And then another 00:28:44.560 --> 00:28:48.840 Matt: thing in the repo can say, oh, I'm going to add that internal dependency on my new lib. 00:28:49.500 --> 00:28:51.080 Matt: And I'll just sort of do a similar resolution. 00:28:51.480 --> 00:28:51.580 Matt: Okay. 00:28:51.920 --> 00:28:56.240 Scott: So I don't think our internal dependencies are like moot point, really. 00:28:56.480 --> 00:28:59.060 Scott: I don't think they're actually added to the root package.json, 00:28:59.520 --> 00:29:02.040 Scott: but rather there's another way that the collects the information about it, 00:29:02.040 --> 00:29:03.260 Scott: that we create some sort of file. 00:29:03.560 --> 00:29:04.540 Scott: I'm pretty sure this is it. 00:29:04.540 --> 00:29:05.620 Scott: I just forget exactly what it is. 00:29:06.080 --> 00:29:09.480 Scott: We create some sort of file to say, hey, this is a library, recognize it, 00:29:09.860 --> 00:29:11.460 Scott: and then it gets pulled from there. 00:29:11.740 --> 00:29:14.460 Scott: But it's a little bit more of a complex internal system 00:29:14.720 --> 00:29:17.040 Scott: that just allows you to do one version rule 00:29:17.820 --> 00:29:20.560 Scott: without giving applications and libraries the choice 00:29:20.820 --> 00:29:22.580 Scott: about even pulling in a version. 00:29:23.980 --> 00:29:24.780 Scott: Probably overkill. 00:29:25.160 --> 00:29:29.140 Scott: I don't know enough about the entire architecture yet 00:29:29.300 --> 00:29:31.340 Scott: to say, like, why did they do that? 00:29:31.480 --> 00:29:34.440 Scott: Is it just for the one version rule, or is there more to it? 00:29:35.900 --> 00:29:39.080 Scott: A lot of our internal tools are quite robust 00:29:39.340 --> 00:29:41.220 Scott: in the sense that, like Wayfair, 00:29:41.320 --> 00:29:42.400 Scott: when we used to have dev boxes, 00:29:44.159 --> 00:29:46.720 Scott: but imagine our monorepo would just spin up 00:29:46.920 --> 00:29:48.220 Scott: every application very easily. 00:29:49.160 --> 00:29:51.100 Scott: Yeah, there's a little bit more caveats to that. 00:29:52.140 --> 00:29:54.240 Scott: We have these things called Hyperloops that power them, 00:29:54.660 --> 00:29:55.240 Scott: make sure they render. 00:29:56.350 --> 00:29:58.940 Scott: You have to set everything up for that. 00:29:58.940 --> 00:30:00.640 Scott: But we essentially have our own internal script 00:30:01.070 --> 00:30:04.780 Scott: that allows you to spin up every application a lot 00:30:04.780 --> 00:30:05.080 Scott: simpler. 00:30:06.300 --> 00:30:08.900 Dillon: So it sounds like at HubSpot and Airbnb, 00:30:09.480 --> 00:30:10.900 Dillon: these are like pretty large companies, right? 00:30:11.130 --> 00:30:15.340 Dillon: You got like 5,000, 10,000 people working there total. 00:30:16.540 --> 00:30:16.940 Dillon: Is that right? 00:30:19.020 --> 00:30:19.560 Scott: Probably more. 00:30:20.780 --> 00:30:21.240 Matt: Yeah. 00:30:22.660 --> 00:30:23.260 Dillon: Yeah, it's a lot. 00:30:24.200 --> 00:30:36.660 Dillon: I'm just getting to like, even at Wayfair, teams this size or companies this size have the backing or the amount of people needed to like invest in internal tooling. 00:30:38.000 --> 00:30:42.900 Dillon: And I'm currently at a place where like all in the company is 600 people. 00:30:43.400 --> 00:30:45.040 Dillon: Engineering is probably like 150. 00:30:46.600 --> 00:30:50.520 Dillon: And I feel like each team is just solely focused on a specific feature set. 00:30:50.970 --> 00:30:53.620 Dillon: We're getting more into like building out platform teams. 00:30:54.560 --> 00:30:56.420 Dillon: but what I've seen that 00:30:57.720 --> 00:30:58.620 Dillon: does for your 00:31:00.020 --> 00:31:01.560 Dillon: application structure is that 00:31:01.660 --> 00:31:03.820 Dillon: you end up just relying on open source tools 00:31:04.880 --> 00:31:06.440 Dillon: for like 99% of use cases 00:31:07.520 --> 00:31:09.180 Dillon: so like for one version rule 00:31:09.180 --> 00:31:10.480 Dillon: we're using something called SyncPack 00:31:10.620 --> 00:31:11.320 Dillon: I've never heard of it 00:31:11.440 --> 00:31:12.520 Dillon: but it basically does 00:31:13.620 --> 00:31:14.920 Dillon: one version rule for you 00:31:16.380 --> 00:31:19.260 Dillon: and I don't really concern myself too much 00:31:19.480 --> 00:31:21.340 Dillon: with the tooling of things 00:31:22.020 --> 00:31:24.480 Dillon: but I'm starting to run up against a lot of issues 00:31:24.800 --> 00:31:27.780 Dillon: where it's becoming really, really hard to do things. 00:31:29.659 --> 00:31:31.880 Dillon: And the main reason is we don't have an internal team 00:31:32.000 --> 00:31:33.440 Dillon: that's focusing on solving those problems 00:31:33.500 --> 00:31:34.820 Dillon: for the developer experience. 00:31:36.160 --> 00:31:37.800 Dillon: So it starts to come down on all the developers 00:31:38.080 --> 00:31:41.360 Dillon: to spread that load across the work they're already doing, 00:31:42.280 --> 00:31:45.780 Dillon: which I think is not really a great way to solve for this. 00:31:46.720 --> 00:31:48.820 Dillon: So hopefully, I guess what I'm saying is 00:31:49.140 --> 00:31:51.320 Dillon: I hope my company invests more time 00:31:51.340 --> 00:31:55.880 Dillon: and money into internal tooling and having dedicated team members that are working on that stuff. 00:31:56.720 --> 00:32:03.300 Dillon: Because hearing your guys' perspectives of like the tools you have in place to help you deal with this 00:32:03.340 --> 00:32:05.920 Dillon: while you can focus on your future work does sound really nice. 00:32:06.220 --> 00:32:07.660 Dillon: And I do kind of miss some of that. 00:32:08.560 --> 00:32:13.900 Dillon: Having a team that could like, I could hand off some of those problems too, 00:32:14.240 --> 00:32:17.520 Dillon: and they can come back to me and be like, hey, I fixed this for you. 00:32:18.180 --> 00:32:19.640 Dillon: And now you can continue your future work. 00:32:20.420 --> 00:32:23.500 Dillon: It's really hard right now for us to be like, 00:32:23.600 --> 00:32:25.500 Dillon: hey, we're going to upgrade to React 19. 00:32:27.260 --> 00:32:28.980 Dillon: And then somebody starts to do it, 00:32:29.060 --> 00:32:29.880 Dillon: and then they don't have time, 00:32:29.960 --> 00:32:31.120 Dillon: and then it just sort of fizzles out. 00:32:32.620 --> 00:32:34.080 Matt: Certainly the tooling that we have, 00:32:34.620 --> 00:32:36.900 Matt: we wouldn't be as successful as we are 00:32:37.480 --> 00:32:39.520 Matt: at a company of our size without the tooling 00:32:39.800 --> 00:32:41.840 Matt: that we have for managing dependencies at HubSpot. 00:32:42.380 --> 00:32:44.360 Matt: But I think also you can get... 00:32:45.060 --> 00:32:45.540 Matt: I don't know. 00:32:45.760 --> 00:32:48.980 Matt: It's like we have McDonald's at home sort of meme. 00:32:49.280 --> 00:32:52.920 Matt: you can get some of those benefits with some open source setups, right? 00:32:53.180 --> 00:32:55.140 Matt: Like, you know, like we tried this at Wayfair, 00:32:55.180 --> 00:32:57.440 Matt: but not too much success, but like Dependabot, 00:32:58.180 --> 00:33:00.880 Matt: I think in a smaller team and a smaller code base 00:33:01.220 --> 00:33:02.980 Matt: could work very well for managing dependencies 00:33:04.320 --> 00:33:07.100 Matt: or, you know, renovate whatever the latest and greatest 00:33:07.200 --> 00:33:09.980 Matt: of that sort of tooling that basically it's like 00:33:10.120 --> 00:33:12.240 Matt: sort of automated dependency upgrades that opens PRs 00:33:12.340 --> 00:33:13.940 Matt: for upgrading dependencies for you automatically. 00:33:15.340 --> 00:33:18.480 Matt: So like you can get some of those benefits like that 00:33:18.500 --> 00:33:21.340 Matt: in a smaller code base. I think once you get to a very large code base, 00:33:21.390 --> 00:33:26.360 Matt: it starts to become more of a pain, I think. Um, I think also like, you know, 00:33:26.520 --> 00:33:30.300 Matt: not to necessarily sort of, uh, make this another AI episode, but I think, 00:33:30.370 --> 00:33:33.840 Matt: I think there's a lot of opportunity for running something like renovate or 00:33:33.960 --> 00:33:38.560 Matt: whatever, but with an AI sort of agent backing it. So it can do the, you know, 00:33:38.800 --> 00:33:41.200 Matt: the major breaking changes where you actually need to make changes to your 00:33:41.280 --> 00:33:45.300 Matt: code base to adopt the new upgrade, like let, let an agent do that for you and not, 00:33:45.420 --> 00:33:48.940 Matt: not have a software engineer dedicate their time to it towards that. 00:33:49.720 --> 00:33:52.380 Dillon: I mean, also with these tools, like I'm saying, 00:33:52.440 --> 00:33:54.820 Dillon: it takes too much, too much of my time to do it. 00:33:55.360 --> 00:33:59.760 Dillon: Maybe I should be like leaning on agent, coding agents or whatever 00:34:00.480 --> 00:34:03.060 Dillon: to solve these problems for me, like set these things up for me. 00:34:03.980 --> 00:34:04.100 Matt: Yeah. 00:34:05.140 --> 00:34:06.100 Scott: I think the path you guys 00:34:06.100 --> 00:34:07.220 Scott: are talking about makes sense, 00:34:07.420 --> 00:34:11.380 Scott: but like I have a philosophy that like building something important 00:34:11.399 --> 00:34:15.360 Scott: by committee never seems to work, not without a solid foundation. 00:34:16.500 --> 00:34:18.100 Scott: It usually needs a team around it. 00:34:19.460 --> 00:34:23.240 Scott: And it doesn't mean it needs to be a long-term team, but it's usually a problem 00:34:23.320 --> 00:34:27.000 Scott: of lack of focus on something critical because you're misinterpreting the business needs 00:34:27.700 --> 00:34:31.200 Scott: and it solves an undervalued hurdle. 00:34:31.820 --> 00:34:34.639 Scott: So often, oh, if we just had X, 00:34:35.540 --> 00:34:38.560 Scott: we could do Y and not stopping to fix that problem or 00:34:38.840 --> 00:34:40.760 Scott: or whatever, it's a tiger team, 00:34:41.060 --> 00:34:44.560 Scott: or we just set aside time to get across that point, 00:34:44.659 --> 00:34:45.220 Scott: solves a problem. 00:34:45.740 --> 00:34:47.480 Scott: This is like my take with like, 00:34:48.159 --> 00:34:50.460 Scott: I think you can have a component library and design system, 00:34:50.500 --> 00:34:52.899 Scott: but if you don't do the foundational work 00:34:52.960 --> 00:34:54.040 Scott: to be like, these are the rules, 00:34:54.340 --> 00:34:55.520 Scott: this is what we're going to adhere to, 00:34:56.280 --> 00:34:57.780 Scott: and then get people on board, 00:34:57.960 --> 00:34:59.740 Scott: it's not easy to be successful. 00:35:00.340 --> 00:35:03.840 Scott: Like some of these things by committee are very difficult. 00:35:05.060 --> 00:35:11.040 Scott: So if you don't, if you have a lot of framework level problems, like solving them just by 00:35:11.260 --> 00:35:15.660 Scott: committee and passing and not, and not taking time to focus on it is difficult. 00:35:16.160 --> 00:35:18.980 Scott: Like, I do think you don't need a permanent team around it. 00:35:19.040 --> 00:35:24.820 Scott: I'm not advocating that, but sometimes these tech debt, like issues that people recognize 00:35:24.960 --> 00:35:28.160 Scott: as an issue, but don't know how to stack up in value. 00:35:28.300 --> 00:35:32.280 Scott: This is what I think like Kristen did so well at Wayfair and was like, Hey, we need a design 00:35:32.300 --> 00:35:36.960 Scott: system because we need consistency because we need to stop making the same button 3 000 times 00:35:37.600 --> 00:35:42.860 Scott: and building something around that like really empowered folks and when it became so mature 00:35:44.900 --> 00:35:48.180 Scott: people were like do we really even need this because all the problems went away 00:35:50.860 --> 00:35:54.660 Matt: yeah i think like kind of maybe restrain what you're saying scott i think it's like the tragedy 00:35:54.760 --> 00:36:01.000 Matt: of the commons right if you don't have some sort of process or team or workflow set up to manage 00:36:01.000 --> 00:36:04.020 Matt: dependencies, just no one's going to do it. 00:36:05.520 --> 00:36:08.880 Matt: I feel like this is the same thing we've been saying, sort of reiterating maybe the same 00:36:08.920 --> 00:36:12.840 Matt: point, but it's like you really need something to help do that. 00:36:13.020 --> 00:36:16.580 Matt: Otherwise, you fall into that, like we were saying earlier, negative feedback cycle of 00:36:16.800 --> 00:36:20.860 Matt: no one does it. You get further and further out of sync. No one does it because it's further and further 00:36:20.940 --> 00:36:23.460 Matt: out of sync and just keeps iterating. 00:36:25.120 --> 00:36:28.780 Scott: Things can become common pieces and commonplace 00:36:29.540 --> 00:36:31.500 Scott: when they're mature enough to live on their own. 00:36:32.020 --> 00:36:36.680 Scott: You can't just expect everyone to care about dependency management 00:36:38.630 --> 00:36:41.560 Scott: in an environment where no one's doing it 00:36:41.560 --> 00:36:43.740 Scott: or everyone's working on their own initiative. 00:36:44.320 --> 00:36:47.420 Scott: You need to build something that's mature enough 00:36:47.420 --> 00:36:48.740 Scott: and strong enough to be able to survive. 00:36:49.130 --> 00:36:50.880 Scott: I'm not advocating that everything can. 00:36:50.930 --> 00:36:53.460 Scott: I'm saying some things can live on their own. 00:36:55.119 --> 00:36:55.760 Matt: All right. 00:36:57.880 --> 00:37:00.320 Matt: What else do we have to say about dependency management? 00:37:00.400 --> 00:37:01.980 Matt: We covered one version rule a little bit. 00:37:03.300 --> 00:37:06.280 Matt: We talked about how HubSpot and Airbnb manage it 00:37:06.520 --> 00:37:09.340 Matt: and Whoop, you guys are basically doing 00:37:09.880 --> 00:37:11.680 Matt: what I would say maybe vanilla dependency management, 00:37:12.620 --> 00:37:14.920 Matt: a lot of open source using tools off the shelf. 00:37:16.520 --> 00:37:18.560 Matt: All right, let's call it there. 00:37:18.700 --> 00:37:21.560 Matt: I guess we can jump into our standard updates, 00:37:21.800 --> 00:37:23.620 Matt: but if people have further thoughts or questions 00:37:23.840 --> 00:37:25.680 Matt: about dependency management that they want us to talk about, 00:37:26.980 --> 00:37:32.940 Matt: reach out in the community discord server or on blue sky or or via text scott loves getting sort 00:37:32.940 --> 00:37:38.840 Matt: of random texts and dms from our listeners about the episode so send them his way um 00:37:38.840 --> 00:37:40.060 Scott: great 00:37:41.220 --> 00:37:45.060 Matt: scott what's your stand-up update for today what shareholder value did you deliver 00:37:46.180 --> 00:37:52.320 Scott: none matt i was going to talk about my personal life uh well i've been doing a lot of like dad 00:37:52.340 --> 00:37:59.720 Scott: chores at home which is i have today off and yesterday uh i said today tomorrow uh yeah 00:37:59.960 --> 00:38:03.320 Scott: yesterday and today off yesterday was juneteenth see look at i've been so busy i don't even know 00:38:03.360 --> 00:38:08.500 Scott: what day it is anymore uh i i started but i did talk about i started refactoring my um 00:38:09.980 --> 00:38:15.140 Scott: accessibility hook i wanted to bang it out today this weekend we'll see it's probably not going to 00:38:15.200 --> 00:38:20.800 Scott: get done but i i started basically rebuilding it it's probably going to be a either a major version 00:38:20.820 --> 00:38:27.060 Scott: release or I'm just going to release something entirely new because I could keep the API, 00:38:27.560 --> 00:38:32.220 Scott: but I've simplified it and I'm like, ah, it's better now. So I've been working on that, 00:38:32.630 --> 00:38:39.380 Scott: adding some features to it. At work, I'm still working on visual diff stuff. It's going to 00:38:39.470 --> 00:38:43.960 Scott: probably be a while. I'm starting to get a little nervous about it, but I'm able to, 00:38:45.240 --> 00:38:49.380 Scott: I prototyped it for the team and they, that will be using it and they loved it. 00:38:50.520 --> 00:38:53.480 Scott: And we were able to break it down into more manageable chunks. 00:38:53.800 --> 00:38:57.920 Scott: We'll just make it purely visual to help folks at first. 00:38:58.020 --> 00:39:03.020 Scott: And then I'm going to try to add some fun features of like copying and pasting and merging. 00:39:03.380 --> 00:39:05.400 Scott: So I'm still working through that. 00:39:05.880 --> 00:39:06.820 Scott: It's been going good. 00:39:07.140 --> 00:39:08.320 Scott: My work on that this weekend. 00:39:09.020 --> 00:39:11.020 Scott: I know that's terrible, but I kind of need to. 00:39:12.260 --> 00:39:15.500 Scott: Dillon, where's your shareholder value? 00:39:18.760 --> 00:39:19.740 Matt: It's with the shareholders. 00:39:20.160 --> 00:39:22.140 Matt: obviously you delivered shareholder yeah 00:39:22.140 --> 00:39:30.100 Dillon: i have a lot of years um now lately or just yesterday 00:39:30.520 --> 00:39:36.860 Dillon: actually this is horrible i had the day off and i spent the whole day like vibe coding 00:39:37.950 --> 00:39:38.640 Dillon: isn't that just 00:39:38.640 --> 00:39:40.460 Dillon: terrible wait or nice oh 00:39:40.460 --> 00:39:40.680 Matt: that's 00:39:40.680 --> 00:39:41.500 Matt: vibe coding 00:39:41.500 --> 00:39:45.120 Matt: for work or for personal yes 00:39:45.120 --> 00:39:47.299 Dillon: uh both 00:39:49.340 --> 00:39:52.600 Dillon: there's like a thing I've wanted to do at work that I just don't have time to do and 00:39:53.540 --> 00:39:55.200 Dillon: don't know enough about to sell it yet. 00:39:57.520 --> 00:40:01.740 Dillon: I've been, basically, I maybe mentioned on a previous episode that I was interested in 00:40:02.260 --> 00:40:08.060 Dillon: like using React Query. And then I was finally like, I was running into a ton of issues with 00:40:09.140 --> 00:40:15.300 Dillon: loading states on a checkout page that has multiple steps. And then I was having inconsistencies with 00:40:15.320 --> 00:40:18.180 Dillon: how is loading in between steps 00:40:18.380 --> 00:40:20.800 Dillon: because each step has different data dependencies and stuff. 00:40:22.820 --> 00:40:23.880 Dillon: So I was like, screw it. 00:40:24.200 --> 00:40:27.160 Dillon: I'm just going to migrate this to React query 00:40:27.220 --> 00:40:28.360 Dillon: and see what it feels like. 00:40:28.880 --> 00:40:30.880 Dillon: So I spent pretty much all 00:40:30.880 --> 00:40:33.260 Dillon: of yesterday doing that. 00:40:33.780 --> 00:40:34.580 Dillon: I learned a ton, 00:40:35.280 --> 00:40:37.960 Dillon: and I actually feel pretty good about what I ended up with. 00:40:39.100 --> 00:40:42.380 Dillon: It's like a good mix of prefetching on server components 00:40:42.820 --> 00:40:44.400 Dillon: and dehydrating that data, 00:40:44.560 --> 00:40:49.040 Dillon: passing it down as props and then reusing the same query, 00:40:49.390 --> 00:40:54.960 Dillon: like keys on the client and using mutations and things like that. 00:40:55.430 --> 00:40:56.580 Dillon: And adding the, 00:40:57.360 --> 00:40:58.460 Dillon: the tan stack dev tools. 00:40:58.840 --> 00:41:00.200 Dillon: Like once I get it all set up, 00:41:00.200 --> 00:41:00.560 Dillon: I was like, 00:41:01.140 --> 00:41:01.940 Dillon: this is pretty sweet. 00:41:02.580 --> 00:41:03.760 Dillon: I'm like kind of glad I did this. 00:41:03.940 --> 00:41:07.820 Dillon: And I feel like we're supposed to have a hackathon next week. 00:41:07.820 --> 00:41:08.120 Dillon: And I'm like, 00:41:08.740 --> 00:41:09.720 Dillon: maybe this is my hackathon. 00:41:09.770 --> 00:41:10.260 Dillon: I'll just like, 00:41:11.140 --> 00:41:11.500 Dillon: this 00:41:11.500 --> 00:41:12.200 Dillon: is the new way 00:41:12.200 --> 00:41:13.660 Dillon: we fetch data or something. 00:41:13.820 --> 00:41:14.720 Scott: that 00:41:14.720 --> 00:41:21.160 Scott: sounds way better than what I was doing with use query where it was like this had if this 00:41:21.360 --> 00:41:27.780 Scott: hasn't loaded render a loading state everywhere and I was like this feels so wrong and then I 00:41:27.850 --> 00:41:33.300 Scott: tried to pull suspense queries in and it was a little better but yeah okay 00:41:33.300 --> 00:41:34.220 Scott: do 00:41:34.220 --> 00:41:34.780 Scott: you have a repo 00:41:34.850 --> 00:41:36.260 Scott: for that I would love to plug it in the 00:41:36.260 --> 00:41:36.760 Scott: show notes 00:41:36.760 --> 00:41:38.260 Scott: if that's personal stuff 00:41:38.260 --> 00:41:41.740 Dillon: it's personal I can I can 00:41:41.740 --> 00:41:50.520 Dillon: share like a sort of chat gpt summary of the concepts covered and like what i and what i used 00:41:51.160 --> 00:41:57.300 Dillon: like to build the build it out but yeah it was it was fun i got stuck on something stupid along the 00:41:57.380 --> 00:42:04.520 Dillon: way we this i'll quickly touch on it we use react i18n which is a library for like 00:42:05.560 --> 00:42:06.080 Dillon: internationalization 00:42:06.080 --> 00:42:10.180 Dillon: yep and for whatever reason we're using this like use translation hook 00:42:13.539 --> 00:42:16.940 Dillon: that dynamically loads the translations. 00:42:18.040 --> 00:42:19.040 Dillon: I don't know if anyone's running this. 00:42:19.960 --> 00:42:22.880 Dillon: But what ended up happening is I would client render a component 00:42:23.700 --> 00:42:24.700 Dillon: that pulled in translations. 00:42:25.680 --> 00:42:30.460 Dillon: And it was hitting my loading TSX in Next.js. 00:42:31.700 --> 00:42:34.980 Dillon: And I was ripping my hair out like, what is happening? 00:42:36.240 --> 00:42:43.640 Dillon: And come to find out, I think that library was throwing a promise or something 00:42:45.340 --> 00:42:49.820 Dillon: and triggering my suspense boundary, and it was blowing my mind. 00:42:49.830 --> 00:42:52.340 Dillon: I was like, what is happening? 00:42:54.020 --> 00:42:56.480 Dillon: And then I was like, I'm just going to call all these used translations 00:42:57.440 --> 00:43:02.040 Dillon: higher up in the tree so that it loads all of those translation files. 00:43:03.300 --> 00:43:07.000 Dillon: it made me think like oh the next thing i need to do is just refactor the entire way we do 00:43:07.120 --> 00:43:16.740 Dillon: translations but it was crazy but yeah that was a fun day of just like i'm not doing work but i'm 00:43:16.920 --> 00:43:20.760 Dillon: kind of doing work i'm doing all the things i wanted to do at work if that makes sense 00:43:20.760 --> 00:43:21.200 Scott: you're 00:43:21.200 --> 00:43:26.800 Scott: doing related learnings that are good and beneficial that's yeah that's great i 00:43:26.800 --> 00:43:27.160 Dillon: was just 00:43:27.140 --> 00:43:31.200 Dillon: This is just going to be a net positive for everyone if it works out. 00:43:32.200 --> 00:43:33.760 Dillon: And I learned a ton along the way. 00:43:36.540 --> 00:43:37.100 Dillon: That was a rant. 00:43:38.080 --> 00:43:38.300 Dillon: Yay. 00:43:39.360 --> 00:43:41.260 Dillon: Matt just did a clapping soundboard. 00:43:42.040 --> 00:43:42.960 Matt: It's not going to show up in the 00:43:42.960 --> 00:43:43.200 Matt: episode. 00:43:44.140 --> 00:43:44.900 Dillon: Not here. 00:43:45.290 --> 00:43:46.280 Dillon: I just reacted to it. 00:43:48.680 --> 00:43:50.000 Dillon: You got to make sure to let someone know. 00:43:51.500 --> 00:43:52.500 Dillon: Matt, what about you? 00:43:54.220 --> 00:43:54.760 Matt: Let's see. 00:43:56.300 --> 00:43:56.580 Matt: Yesterday. 00:44:01.640 --> 00:44:07.700 Matt: yesterday we had the day off also um we were down in stanford this last week so uh we uh took 00:44:07.920 --> 00:44:12.980 Matt: yesterday and went into the city i got pizza at john's on bleaker for those that know it's pretty 00:44:13.140 --> 00:44:20.840 Matt: good highly recommend um and then also went to like the morgan library uh and yeah it was pretty 00:44:20.960 --> 00:44:26.140 Matt: neat uh we got caught in a quick thunderstorm though so we were like drenched for half the day 00:44:26.360 --> 00:44:30.260 Matt: I had to try out in the bookstore, but yeah, it was good. 00:44:31.640 --> 00:44:33.060 Dillon: Wait, wait. 00:44:33.670 --> 00:44:37.180 Dillon: Did you eat pizza at Papa John's son's 00:44:37.180 --> 00:44:37.940 Matt: pizza? 00:44:38.860 --> 00:44:39.600 Matt: I don't know. 00:44:39.720 --> 00:44:40.660 Matt: It's called John's on Bleeker. 00:44:40.920 --> 00:44:41.440 Matt: That's all I know. 00:44:42.460 --> 00:44:44.280 Scott: Is this fiance shareholder value? 00:44:44.640 --> 00:44:46.800 Scott: Like, where's your shareholder value? 00:44:49.480 --> 00:44:49.800 Matt: Let's see. 00:44:49.800 --> 00:44:53.980 Matt: Yeah, in terms of actual shareholder value, I don't know what I've done. 00:44:54.320 --> 00:44:55.800 Matt: I've done a lot of migration work. 00:44:57.460 --> 00:45:01.340 Matt: like we're I mean we're talking about like internal tools and stuff for managing dependencies like 00:45:01.340 --> 00:45:08.320 Matt: we have a heavily well like well structured well built out system for running migrations or like 00:45:08.460 --> 00:45:13.300 Matt: code mods and things like that across our ecosystem so I've been interfacing with that a lot but 00:45:13.420 --> 00:45:18.060 Matt: there's like I don't want to go too deep into it but we have this thing called mothership that runs 00:45:18.280 --> 00:45:23.880 Matt: those code mods or migrations and that kicks off builds across all the different sort of libraries 00:45:23.880 --> 00:45:25.720 Matt: in Blazar. And so 00:45:26.280 --> 00:45:27.940 Matt: that Mothership, there's like a dashboard that says 00:45:27.980 --> 00:45:29.880 Matt: like, oh, here's the libraries that failed to build in Blazar 00:45:30.180 --> 00:45:31.920 Matt: in CI. But you have to then 00:45:32.140 --> 00:45:33.960 Matt: click through like twice for each library 00:45:34.100 --> 00:45:35.860 Matt: that failed to build in order to expand the build log 00:45:35.960 --> 00:45:36.820 Matt: to see why it failed. 00:45:38.400 --> 00:45:38.800 Matt: And 00:45:40.060 --> 00:45:42.000 Matt: so I was starting to like hack on 00:45:42.220 --> 00:45:43.800 Matt: something Wednesday of like a little 00:45:44.080 --> 00:45:46.020 Matt: CLI tool that would pull up 00:45:46.160 --> 00:45:47.940 Matt: the Mothership mission, find 00:45:47.940 --> 00:45:49.920 Matt: all the failing builds, get their build 00:45:50.060 --> 00:45:51.540 Matt: logs, and then pipe that into Claude 00:45:52.000 --> 00:45:53.860 Matt: so that it could then sort of like 00:45:54.660 --> 00:45:58.420 Matt: you know summarize like why did this build fail and tell me if I need to just rebuild it because 00:45:58.480 --> 00:46:01.860 Matt: there's like a flaky test or tell me if it's actually like an actual error related to my 00:46:02.160 --> 00:46:10.740 Matt: migrations so um Dillon shared the uh Kazam video on microservices I think that's an accurate thing 00:46:11.600 --> 00:46:11.660 Matt: yeah 00:46:11.660 --> 00:46:17.560 Dillon: should I even ask Blazar and Mothership are black so Blazar 00:46:17.560 --> 00:46:19.360 Matt: is just a CI system actually 00:46:19.380 --> 00:46:21.240 Matt: apparently, I found this out this week, 00:46:21.590 --> 00:46:23.740 Matt: we had originally open sourced it from HubSpot. 00:46:24.100 --> 00:46:25.420 Matt: So there's a public GitHub repo 00:46:25.620 --> 00:46:27.100 Matt: called Blazart, but then we later 00:46:27.840 --> 00:46:29.440 Matt: did an internal fork of it to add 00:46:29.560 --> 00:46:30.860 Matt: more HubSpot-y things to it. 00:46:31.500 --> 00:46:31.920 Matt: And then 00:46:34.940 --> 00:46:35.300 Matt: Mothership, 00:46:35.500 --> 00:46:37.480 Matt: I don't know how it got its name, but it does work. 00:46:38.340 --> 00:46:39.260 Matt: It kicked off builds. 00:46:42.280 --> 00:46:42.620 Dillon: All right. 00:46:42.910 --> 00:46:43.660 Dillon: I think we're out of time. 00:46:46.860 --> 00:46:47.380 Matt: Thanks everyone for 00:46:47.520 --> 00:46:49.340 Matt: tuning in. If you had questions 00:46:49.360 --> 00:46:54.640 Matt: comments, feedback shared in the community discord server on blue sky or text Scott about it. He loves 00:46:55.360 --> 00:46:56.200 Matt: receiving those texts. 00:46:58.200 --> 00:47:02.400 Matt: Otherwise, have a great weekend, everyone. See you next year, 00:47:02.560 --> 00:47:02.900 Matt: month, 00:47:03.120 --> 00:47:03.560 Matt: decade. 00:47:06.440 --> 00:47:08.800 Matt: See you next time. Later.