Jeff: seeing developers work with Node, the most common thing for the last two decades almost has been, uh, forgetting to run npm install after pulling down a branch. Uh, even agents don't do it right. and is ridiculous, I'm sorry. Like this should've been fixed years ago, but I'm fixing it now, with, with just like having that behavior.
[00:00:34] Introduction
Andrew: Hello, welcome to DevTools FM. This is a podcast about developer tools and the people who make them. I'm Andrew, and this is my co-host, Justin.
Justin: Hey, everyone. Um, we're really excited to have, uh, Jeff Dickey back on with us. So Jeff, uh, we had you on what simultaneously feels like, uh, forever ago and then not so long ago. Um, and it's so great to have you back.~~ Um,~~ you are our second episode recently of, like, someone coming back who is, like, releasing a new version of a thing or doing a new thing, so excited to, um, have this new series.
Um, so you are starting a new company, and we're so excited to talk about that. Uh, and you're building some new tools. Uh, so before we dive into all that stuff, could you give our guests a refresher, just, like, do a reintroduction of, like, who you are and what you do?
Jeff: Sure. Yeah. So, uh, my name's Jeff Dickey. I've, I've, been, like, making dev tools and CLIs for a very long time now. Um, my first job was, was writing the Heroku CLI. That was almost 13 years ago now. and ever since then, I just really have loved making dev tools and CLIs. It's just been a huge passion of mine.
And so, uh, after that, I've gone to do that at Facebook, at Amazon, most recently Figma. and yeah, uh, done a lot of open source, you know. Um, my most famous product is, is Mise, which I'm sure a lot of listeners will know. Um, and been working on that for about three years now. It's been, been a huge success, a lot of fun to write. and yeah, like you said, I-- about three weeks ago, I made the decision to sort of find a way I can do this full-time, um, because, know, open source has always been a part-time thing for me. Um, but, uh, I love it so much. I, like, gotta find some way to, do this all day.
Yeah, so let's jump right in right there. Uh, can you tell us the name of the new company and, like, what kind of, like, finally pushed you over the edge of, like, "I'm gonna stop being the CLI guy at a company and just try to do this on my own"?
Yeah. So, so the name of the
Yeah.
is OnDev. Uh, it's... A lot of it's just the domain I got. I got the domain e-n.d-e-v. Um, but I also, like, I had a, a bot that was Mise OnDev. So it was like Mise in dev. Um, and like, uh, you know, 'cause I've always made a lot of tools, and so the, the pattern's always like I, I use my personal domain, jdx.dev, I've always, like, put my tools there in a subdomain.
So it'd be like mise.jdx.dev, hk.jdx.dev, fnox, so on and so forth. So the OnDev kind of works well with that, right? You see Mise OnDev, HK OnDev,
Ah.
kinda, makes sense. And then I have a logo that, like, is inscrutable, but it's, it's a Belgian on dive uh, like a stylized one 'cause that on dive and dev
Fun. So, uh, I've-- The, the website is beautiful. Uh, I see you are creating lots of many, uh, nice AI marketing websites. Lots of tools too.
[00:03:44] Monetizing Open Source
Jeff: Um, so let's, let's, let's keep on the company for a little bit and talk about like the business model. Like what, what are-- how are you gonna be making money with this? Are you gonna be doing like a pure open source thing where you try to just do sponsorships or what's going on?
So, um, so, um, so, so I'm definitely i've got my theory on out, that one, and, and I'm and I'm trying a few things I really
' cause I really don't know.
know, I th- I think the I think the most ideal would be would be sponsorships and also so I'm doing kind of kind of a paid thing. Um, I was actually I was actually collecting interest in a amount about the- money on GitHub Sponsors before, you know, like four or $500 a month. But that was, like, without me promoting it and like the, feel like, and this has been true over the last three weeks, that like people are giving me much more money now that they know this is like a full-time thing. And then, and I'm like And I'm also doing it with like I got a newsletter, I'm doing like a live stream. So, um, so, so that, that's kind of step one that we gotta work out. Definitely not the book. Enough something it's like giving for it. I think that, and I'm know, there's a lot more money in that. Like, so I think it could work out. That, you know, there's a lot more money to be made there.
It's obviously risky and, and we'll see. I don't really know until I try to see how much I can make there. How much it could do there. Um, but it would be nice if I could get internet five days a week just, just and then come back. Cause that, that's the goal
that way. Um, but you know, that way- at potentially doing some consulting for companies which would, which would be really great for both me and the product because if I got to go to different companies and integrate Mees, then I could learn about like where it's falling flat in large companies. so we'll see. I haven't got any takers on that, but, uh... And then lastly, I'm, I'm working on some paid services for Mees, which, um, you know, I'm I'm hoping I can like keep that down to not be like a full-time job of like building a service and like still optimize open source. Um, but we'll see. You know, I'm three weeks in and definitely not sure which, which of these avenues are gonna work out best.
Justin: Well, I mean, it's good that you have, like, optionality. You know, you can figure out what feels good and, like, kinda what you wanna spend more time in. That's the problem with the business is, like, it's very different. You end up having to spend time on things that are not, you know, writing a fun open source project.
You gotta, you know, deal with marketing and sales and, you know, all the other stuff. But, um, you do have a good start. I mean, like, Mees has, like, pretty big adoption, which I think does make this, like, a little bit easier to sort of, like, just get your name out there and, like, get in contact with companies.
Um, so that's, uh, that's pretty exciting. I'm, I'm excited for you. Uh, it's a hard space, I'm sure, but it'll be, it'll be cool to see what you do. Um, so you, you have a, a lot of tools out there, and before we, like, move on to talking about them specifically, um Given that we're on the, the, the notion of your company, is like how are you thinking about like the maintenance of all of these open source tools while you're balancing building products or consulting or, you know, like whatever else that looks like?
It seems like a, a, a lot of, lot of balls to juggle there. So how are you gonna try to like retain your focus and how are you thinking about prioritizing things?
Jeff: Yeah, it is hard right now. You know, the, the, you know, elephant in the room being just AI PR contributions, which, which I'm, I largely like, but it's, it's a lot. Um, now I've chosen to let maintenance take priority over th- everything else. And so every day I sort of clear the decks of, like, going through my GitHub discussions and PRs that people submitted get all that done, but really before I move on to anything else. largely because that piles up and because it's just me, like, it's gotta get done. And, in the past there's been days where I've had to just, like, commit bankruptcy and just, like, delete all the notifications and be like, "Okay, well," you know. I don't wanna have to do that, right? Um, we'll see. I, I'm, I'm sort of this optimist that, like, I'll get to a point where, like, enough of the bugs are fixed with Mees in particular, and, like, we can move on to other things.
Uh, you know, but, uh, yeah. Like, getting, getting the maintenance figured out is, is definitely a big struggle of mine.
[00:08:17] Ad
Justin: Software engineering is a challenging job and it's harder when you're forced to constantly context switch. You have email in one tab, Slack in another, five different Google sheets, so many accounts to keep track of. It can feel like half the job is just dealing with organizational overhead when really we just want to be writing code.
That's where Macro comes in. Macro is a tool to cut through the noise. It's a workspace built for engineers. And it's one place for all your emails, your tasks, your chat, and your documents. The best thing is the source code's available. So if you go on a peek under the hood to see how it works, you can definitely do that.
If you want to extend it, feel free. The back end is rust and the front end is in TypeScript. It's easy to extend to make anything custom. And the cool thing is Macro will pay contributors for any features that they land. So if your team is tired of bloated project management, or maybe you're just like starting fresh and you just want one tool instead of many, give Macro a try.
It's fast, it's fun, it's a better way to build. Sign up at macro.com and get $100 off your subscription using DEVTOOLS100.
Cool. Andrew, you wanna move on and talk about the
Jeff: Uh, yeah, let's, l
[00:09:21] Aube Node Package Manager
Jeff: et's switch to talking about projects 'cause there have been, like the amount of projects just listed on your on dev website is cr- crazy, and they're all just so high quality and look so useful. Let's start off with aube though, or did I say it right? aube, aube?
Aube,
aube. Okay. Let's start out with aube
Uh, you wrote a Node.js package manager. There's a whole lot of those. Why did you set out to do that, and what makes it special?
It was actually my second one. I, I wrote one about 12 years ago. Uh, I never released it, but, uh, I really like package managers. Um, just it's, it's a big passion of mine. I like reading about them, reading the source code. Like, just I've always been into it. I particularly like the Node, um, ecosystem. Uh, I'm, I'm really not a Node developer anymore. Everything I do is in Rust, but, um, I don't know. Something about Node just has always tickled me. I, I like it for some reason. And, um, and I also think everybody's kinda doing things wrong in, in a few ways there. Um, you know, I, I think that th- there's a lot of reasons why I thought, like, the time was right to, this, that it would make sense.
But, but the biggest one is just that I thought that there was room for a native compiled Node package manager is that you're using Node and not a different runtime, like Deno and Bun, right? Um, 'cause I-- What I'm seeing is, like, developers, Node and they wanna stick with Node. Um, and of course, like, you can use Node and use Deno, use Bun to manage your packages, but it, it makes some assumptions that that's not the case, right? run Bun run, it's gonna run under Bun, right? Like, um, like that. So, I, I thought there was room for that, and I, I thought nobody was working on it. Um, but come to find out Yarn actually was. They have a package manager called ZPM, which, which they were actively working on. I don't know that much about it, but, but yeah. It's like, you know, that's kind of the idea is, is native compiled so it's fast, um, above all. Um, and then there's, like, some smaller things like, you know, being brand new, I get to make a clean break and fix things that I thought were wrong with the ecosystem.
Like, for example, package manager out there has its own, its own lock file, and I always thought that was ridiculous. Like, it should just be compatible. So aubea out of the box is just compatible with all of them. It's Switzerland. Um, you can use Package Lock, you can use Yarn Lock, use Bun Lock. It's all good. Um, know, a lot of the security stuff, like the, the post install hooks with Node is like, seems like number one by far way that vulnerabilities are happening across the industry. I just took 'em out, right? And in the rare case that you do need 'em, aube has a jail, so it can run those in a, in a sandbox.
Uh, you know, it's, it's not gonna prevent every issue, it'll get the easy ones that is the attacks that are happening, right? and then also there's a, a thing called the global virtual store, which come up with. Pnpm was already doing it. but it basically lets you put all the dependencies into a directory in your home directory, and then, like, your node_modules directory is just a bunch of symlinks, right? So that makes things really fast, and it uses very little disk space It doesn't matter how many times that like 13.0.0 is on your system, it's just referenced in one place. Um, no other package manager has that on by default like Oak does, because it, it, it doesn't work everywhere. It doesn't work with big ecosystems like Vite and, and, uh, Next.js, for example. Um, but, you know, knows that, and so if you have those projects, it just w- it just won't turn it on, and then it'll just perform as fast as pnpm or Bun does. but my intention is to push the industry forward so that we can get all these ecosystems onto the GPS,
Yeah, a lot of people have tried to do plug and play, which is, uh, what you're describing, where it's like the, you have the home directory of things. But when Yarn came out with that way back in the day, it was like pain on pain on pain, 'cause they did none of those things. Uh, and yeah, it was just a real hard time.
So like, did you have to deal with anything with like TypeScript or anything like that? Is there like a, an eject that you have? Like if I like wanna go like edit a node, my node modules to debug things? Well,
Well, uh, so this is set up with, uh, with hard links. So you
go into directory
and it's just, you know, it's, it's as if you were using pnpm. It, it uses a lot of the same structure. Um, obviously if you start modifying stuff, then that's gonna happen everywhere. Um, but I don't think there's any fixing that.
That's just how it is. Um, but, you know, I think pnpm has really moved the industry forward over the last few years. A lot of people have adopted pnpm, and so like, you know, having that, that local model has fixed a lot of the hoisting problems and a lot of things. It's definitely not perfect, but, it's a lot better than it was.
And so, yeah, I mean, basically, like what I'm saying is as long as you're not using one of like five packages, you know, ones, Vite, Next.js, but, seems like it's working great, right? I've, I have had very few, uh, mentions of GPS not working. It has happened, um, but like, you know, in all my projects it's been working great, which is, which is awesome to see.
Justin: I wanna just like talk about PMPM for a second because it seems like that's the biggest direct competitor. Now, you said, um, for aubeey you like-- you're compiling it, so it's like really fast, um, and seems like to be one of the core sort of features. Uh, PMPM is like really trying to push a performance envelope too that's like One of their big things.
And I'm curious, like, beyond some of the other things that you talked about, like lock file compatibility, what, what was the big thing, you know, when you think about pnpm that, like, separates as like, you know, this just isn't enough, or it's not going far enough, or it's not doing what I think it should do?
Like, are there, like, specific things when you were looking at that that sort of like jumped out at you?
Jeff: Yeah. I mean, one thing is I, I think that pnpm is moving in a direction of like- trying to be the package manager. You know, like they're re-implementing all of the npm features and stuff. Um, they're really kind of going against compatibility and, and trying to own the ecosystem themselves. Um, whereas I, I think that's a big mistake, right?
I think that like maintaining npm... I don't think npm is ever gonna go anywhere. Npm's always gonna be the most popular package manager for Node. This is the alternative if you want it to be faster, right? Um, as a result, it needs to cooperate with Node, with npm. Uh, and then also like I, I just think that, um, you know, like one of the things I've done with aube that, uh, I need to work on like explaining this in the landing page better, but like the, the, the TLDR is if you're using aube install, you're not using it right.
You should never run that, Um, aube has a different model than the other package managers where it installs by default, right? And so I come from Rust and Cargo, that's just how things work. You run Cargo run, it's gonna compile stuff if it needs to compile, and it does it so fast that like matter, right? the equivalent of that with npm would be npm install and, and npm run test. too slow. Nobody wants to do it. pnpm has a native command for this, pnpm install-test, but it's still really slow. Uh, you know, and so with aube, like I, I have like the kind of a hidden like state file that I use with a bunch of checksums that like can super quickly validate if it needs to install. and, and that's how I can get it like sub 10 milliseconds, right? So if you do like aube run test, then, um, it's, it's just by default it's gonna run install if it needs to happen. 'Cause being, you know, working at DevInfra for a long time, seeing developers work with Node, the most common thing for the last two decades almost has been, uh, forgetting to run npm install after pulling down a branch. Uh, even agents don't do it right. and is ridiculous, I'm sorry. Like this should've been fixed years ago, but I'm fixing it now, with, with just like having that behavior. So yeah.
Justin: Thanks.
Jeff: So there's a lot of features that, like, I've come to rely on in a package manager, probably the biggest one being Workspaces. Does, uh, Opes support Workspaces and kind of like those more nitty-gritty detail features? Like, another one I use a lot is overrides, like when I have to, like, force a f- a certain version of a dependency to make the types work.
Yeah, yeah, because, uh,
I test cases
and
and,
bug fixes and every little
little feature
feature there
used. Used.
Um, but I'm at but I'm at a point now where I'm fixing bugs and nobody can use pnpm.
Uh, and I have no I
how popular have no idea why.
features are.
I think
I might need a very, very bumpy rider.
but I I want to be in a
for pnpm, right? Where, uh, you can just-- If you were using pnpm before, world where, like, where, um, using pnpm is easier than using any package manager to work with, like,
pnpm, pnpm.
um, 'cause I think that's setting up a small script that's
right? That's that's the alternative, but faster and focused on the same thing, but it's more custom to pnpm. Um,
and and so, yeah, like,
I've done a i've done a lot of work around that tier dependency
were for
way way harder things than I've ever done.
But I think I i'm done.
Justin: Cool. Maybe one more question before we move on and talk about some of your other tools that you've made since we last talked. Uh, I wanna hear a little bit more about this gel. Um, so supply chain attacks, uh, happening what seems like every day now, like in massive packages with many, many, many installations, and it's increasingly scary.
So how are you approaching security and like what does that isolation of like post-install scripts and stuff look like?
Jeff: really across all the tools I'm making, this is, this is a big deal. Uh, you know, Mies has some new sandboxing stuff too. Some of the, the service I'm working on for Mies are having remote jails so that, so that I can build your tools for you in a jail. and, and like I was with aube,
you know, I, I, I don't, I don't...
I'm not planning any services for Mies or, or sorry, with aube I'm not planning on monetizing that. But like, wanna at least have jails so that you can run those hooks securely. This is not on by default yet, but I am pushing hard to try to get that done. I'll probably do a breaking change v2 sometime in the next three months, I think, once I get a few of these things stacked up of like, all right, let's make this default behavior. Uh, one of them I think will be the jail. Uh, and so what that does is it in, on macOS, it uses, uh, Seatbelt. Linux, it uses Landlock, uh, and it locks down the network, it locks down the, you know, the, the drive so that it can only access certain things. Um, and so, you know, the most naive attacks, which are the most common of like look around for .env files across your hard drive are not gonna work. Um, so yeah, that's the idea.
But, but again, like the lifecycle hooks are off by default, so you have to like one by one say, "I want this to use lifecycle hooks even with a jail." Uh, and then like the behavior will be like, okay, I've turned on this package. The default's gonna be still running in a jail, so it'll be like three steps to like get a, get a package to run a post-install hook without a jail, which I think is the way it should be. I really like... Dependencies should just not have them, But, uh, it's a reality for right now.
Justin: npm ecosystem is actually used a lot for, is just like to, you know, I have a, a Rust project and I'm also like, you know, distributing it on npm and you have to like pick which is the right binary or whatever, uh, tends to be a thing that you see used.
Jeff: Yeah. I think that might get better with Node 26 because they have the new FFI stuff. So I think...
not too familiar with it yet, but I think that might, uh, mean we don't need to do some of that
~~Nice. ~~Yeah
of the ecosystem, especially like when having to deal with CI stuff. Cool.
[00:21:48] HK Faster Git Hooks
Jeff: Let's move on to another low-level annoying type project that seems like you like to tackle, uh, HK. So HK is your take on git hooks. Can you tell us how it's different than, like, the incumbents?
Yeah.
Yeah. Is completely different. I mean, I think HK, um...
think like Git hook managers have a few different forms. Like
Husky most things are really cool. Making it something you run, um, faster is great because I think the only solution to this is just as, like, the newer the git came out, of weeks ago, you can have global hooks, you have to keep up. Ooh. That because they, they like add stuff inside of the repository that's like really a lot of that and you just have it run all over the place. Just work in every project, and that's what you should do, right? So so
yeah, in that category, I now, uh, or on the way out. And then there's working well. And then there's the category of... And that's kind of
You're where things they run like, uh, where where you pre-commit, you have have to plug everything in and you don't have control. So, uh, and know how to I think everyone runs Prettier or whatever it might be um,
and and then HK is really a level beyond that
with where pre-commit, it's, it's like,
it, it can you can go and really save from like series. Because like it's probably dead in the file or made. Um, and it's not generally safe to run in run in parallel. Let's say ESLint and Prettier at the files time because they work on the same files. So in HK's, the is reason it's safe is because safe is because hK, like, keeps integration with the tools. So it runs,
Ruff, for run, for example, it'll run it or run with diff. Dev.
And so
doesn't it doesn't have to run everything that changes on dev.
it it just asks for everything that you've marked today, and HK itself knows.
And so so
that's that's literally faster and practice
any other tool because it than any tool because it can, can, can run all those parallel safely. In parallel.
And then
and it also like,
it, it has a
it has a bunch of built-ins.
like,
So like down to the edge, if you configure it to run,
how to configure it correctly. But
like, by the way, with that, it would just add at least 100 built-ins that just are already in there. So there's no extra
Justin: That's awesome. So it, it's trying to, like, for a lot of the, like, formatting tools, it's like you have, you know, ESLint that's doing some formatting and Prettier that's doing some formatting, and you're trying to, um, figure out, like, what the outputs would be and, like, composing those together. What if there would be conflicts between the two tools that you're running, um, parallel.
Like what, what would-- It just runs it again? Ah, gotcha.
Jeff: So, and, and it'll, it'll run a subset, right? So if that happens, it's gonna be on, like, one file, right? And so then it can run a subset. This doesn't work with every linter. So there's sort of different levels of, of integration.
Justin: Gotcha.
Jeff: dash diff. Some of them can only work by editing the files directly. And so HK does a bunch of stuff. So one of the things it'll do is if, if the linter offers the ability to tell you which files have issues, which let's say Prettier does. Prettier does not have diff dash dash diff, but it does-- it will tell you which files have issues. there's a, there's a whole, like, read, write lock thing.
So first thing HK does is it gets a catalog of here's all the files in the repo, has read write locks. And so it'll get a read lock on, say, all the JavaScript files, run Prettier and say which files have issues. We get that list back and it'll say these two, and it gets a write lock, so that's an exclusive lock on those two files, and it runs the, the fixer on it, And so that's, you know, that's kinda how it works. And, and, you know, in some tools, they need write access on all of them. It's the only way they work. And so with those, there's no choice. It just has to get an exclusive lock on all those files. You know.
Justin: That's really interesting. Um, that's cool. One of the other sort of like design decisions that I wanted to ask you about, um, so it's a little bit of a diversion from the previous topic, but, uh, so HK is like configured with this, uh, script, uh, this configuration language called PKL. Pickle maybe? I don't know.
Uh, not, not to be confused with like, uh, pickling in, in, in Python. Um, so can you, can you, uh, tell us a little bit about PKL and like why you chose that? I think this is the only project that I've seen use this configuration language, and it was like kind of fun to stumble across, so curious about that.
Jeff: it comes from Apple, which is fascinating, right? Like, I can't think of another open source project aside from maybe some of the BSD stuff they do. Um, yeah. So, so Apple may... I don't know what Apple used it for. Uh, I don't know if it's anything public. But, um- It is sort of in vein of maybe, I would say, Nickel and a few of these other sort of like compile to YAML languages, might be fair to say. to TOML, compile to J- to JSON. Um, and it, and it lets you just do templating basically, I think is a way to think about it. Like it, it, and it's, it's safe. So like if, if, if you like import a, um, Pickle file, there's, it, it can't like, you know, run commands and execute things, right? Uh, like if you import a Python file, for example, it would be very dangerous, right?
But like Pickle, it, it, it's, what's the word I'm looking for? Pure, right? Um, and so ultimately HK gets this JSON representation of the Pickle. Now, the reason I'm using it is because, um, you know, the, the built-ins I was talking about, that's all written in Pickle. And so that it, it basically has made it so I don't need to have a plugin interface, because the configuration is comprehensive enough and powerful enough with Pickle, for it. Uh, you j- just, you can, you can create really complicated things, right? So like you could have something where, you know, you, you can have your own rules about like, I wanna run just these hooks if this environment variable is set. You know, it's like really powerful things there's no way YAML could do or any other simple configuration language. So yeah, I mean, it's, um, it's something new for a lot of people. I think it's hurt the adoption, frankly. Uh, I don't know if I would recommend people choosing it, but it, it, it was such a solid fit for HK. I'm glad I, I chose it. Yeah. And it's fun, you know?
Justin: Fun name for sure.
I think, uh,
don't know.
I don't know. I'm curious
configuration languages in general kind of stink 'cause, like, JSON's not great. Hmm, YAML's not great. Like, JSON5 has been the one that I've been using most lately, and it's like, you know, it's better. I can comment things and don't have to quote everything.
It's nice. But yeah, uh, the, the sort of like composability of this, like, is really nice 'cause I saw, like, in the docs, it's like, oh, you just, like, import, like, this extra, like, configuration here, and it's like, that's pretty cool.
Jeff: Yeah, you can write your own functions and stuff. It's, you can do-- It's extremely powerful. Yeah.
Justin: Cool.
[00:29:16] HK and Mise Integration
Justin: Um, I, I think we'd be remiss if we didn't talk about, um, how this intersects with Meese. Uh, so it's like Meese is sort of your, your like, you know, central project and, and a lot of the tools that you build in some way, like, have integration. So it's like, what is the, what is the HK, like, Meese story like?
Jeff: there's really very little, and, and that's intentional. So like, uh, th- there is like Mies integration in HK, but like it, it does such s- all it does is it prefixes stuff with Mies execute, Mies X. So that like all the tools are loaded by Mise. you know, I could have gone a route where you could have a tools field in the HK pickle config where you could say like, "I want this version of Node to run this thing." I haven't done that because it's not necessary, right? Like, like the, the thing that like Mise does really well is it, it's really easy to do that with any... Anytime you've got Bash, which is what's in your pickle file, then you just do Mise X Node at 20, and then now all your Prettier stuff's running under Node 20, right? and so like, you know, things integrate, but just by virtue of like, because is already really good at doing that with any kind of shell script, you know? the other place that they-- it's like, you know, there's noth- there's nothing built into Mise around this, but like all of my projects have a Mise run lint and Mise run lint-fix, and then they also have like a Mise run CI, which is what runs in CI, and then that has a dependency on lint. Uh, and then that, that lint is gonna run HK. and, and a lot of people are doing that with HK. In fact, I'd probably guess most HK users are Mise users. Um, and they probably have a task that does exactly what I'm saying. And there's nothing in Mise that describes that. It's just like that's just the natural way that you would do it.
Uh, you know. And so I think like, I don't know, like we've got the fundamentals figured out after years of working on this and like these things just sort of interoperate together because it's built on Unix, I think is kinda, kinda the long and short of it.
[00:31:23] Fnox Secrets and Leases
Jeff: let's move on to something the docs, uh, literally call out. This could have been in Mees but isn't, uh, Knox. Uh, Knox is your secret manager. Can you tell us how this one's different and why it wasn't in Mees? Yeah, so, so secrets
something that people wanted from Mise for a long time. Secrets are a really hard problem. Uh, and so part of the problem is Mise runs all the time. So if you run Mise X, if you enter a directory and have Mise activated, Mise has to sort of refresh all of its environment variables. Um, you know, and if that's just Node env equals development inside of Mise.toml, It's no problem, right? What people wanted was one password, right? They wanted to have, I want my environment variables loaded from a secret in one password or Amazon Secret Storage or any kind of remote provider. And I never implemented that because it'd be incredibly slow, and you can't cache it, right? Because these are secrets, right? Like, uh, y- you don't want to put them in a plain text file on disk somewhere, even encrypted, because then that key, I need a way of decrypting it, right? So it's very dangerous for me to do that, and so that's why it was never done. Um, by virtue of like being a separate tool and F Knox just doesn't have to run as frequently, right? So like every time you run Mise run, it's gotta load that environment. but because F Knox run separately when you enter the directory or run fnox exec, and it's only running really when you tell it to, and so it's cheaper. Um, the other thing I really admired was a tool called SOPs. so SOPs is sort of encrypted JSON, and what it's commonly used for is to have encrypted environment variables of secrets in your repo, and then use something like Augie to decrypt it. Um, and so I, I really like that pattern. Um, I've seen it used in a lot of companies.
It works really well. And so to integrate those two worlds because, you know, the pattern that I'm seeing that I really wanted was like, have secrets in, let's say, 1Password, I wanna encrypt them with a KMS token from my company's AWS account, um, and store those on disk and, and not committed. You know, let's just leave it, like, on the developer's machine. Um, and then that, that sort of gives you, like, a nice balance of being fast and secure, uh, kind of all at the same time.
Justin: Yeah. I, I, I really appreciate this project a lot 'cause, like, uh, I didn't, I didn't realize it was called Auge. I, I thought it was H. But yeah, the, the-- So I've tried to use, uh, SOPs and Auge before, like in, in Like together, but like the DX is a little tricky, especially if you're collaborating with people. If it's like just you, like, 'cause every person has to like create the secret key, you know, that you have somewhere on disk, um, potentially.
Uh, and you have to, uh, you know, re-encrypt the file basically with your, your signature in there. Um, and then like adding new team members is this weird song and dance where, you know, it's like, "Do you, you pass your, your key to me?" Or like, how do I, you know, you go, "Give me your public key and I'll list it and re-encrypt it or whatever."
I don't know. It just felt strange. And I, and I do enjoy how that experience is like improved. It feels like you, you did elevate the, the DX of that. And also just like being able to then like integrate something like 1Password or whatever just into that same flow is nice because like, you know, I can get the secret from 1Password to do the thing and like it's, um, yeah, it's, uh, it's pretty nice.
Um, is there any like other features, uh, of, of F Nox that you feel like is like kinda under socialized, like something that you're really proud of that like people might not discover, like...
Jeff: so there's, there's stuff with, um, leases, and I, I don't, I, I wouldn't say I've nailed the DX here, but I like the direction. Uh, actually, a lot, like, uh, fnox DX-wise I think is a little unfinished for me. Like, I, I like what it is. It, it's got room to improve. Uh, whereas like with HK, I think HK is very mature.
I think I've... The DX is, is quite good there. I think with, with fnox... So, so, like, a lease is, uh, short-term credentials Right. So, so the dream I have is like, especially with agentic programming, some way that an agent can say, like, "Give me a Cloudflare token that's good for an hour." Right? And, and maybe, like, I can get a prompt on my phone to, like, even approve that.
And there's, like, no way the agent can get to access to the long-term credentials somehow. Um, I don't quite have this. Leases are, like, part of the way there. So with a lease, you can do something like store, uh, something encrypted that can get decrypted with a YubiKey, for example. So you have your long-term token has to have a YubiKey press, and then that can give you a short-term token that then doesn't need that, right?
So you can do stuff like that. but I'm at the mercy of the providers in some ways, especially GitHub is, like, not very good support for things like this. you know, but, like, that's kind of the thing I wanna solve is, is getting rid of long-term tokens for development, you know? Um, but we'll see. Watch this space for sure.
Justin: Yeah, that'd be cool. I was actually curious about that. I hadn't used leases yet, but
Jeff: Um, so before we move on to talking a little bit more about memes, I wanna ask you about your AI usage, 'cause, like, you have so many projects and they are very high quality. I'm not saying they're sl-slop at all, uh, but to, like, do this much work, you must be using AI in some way. So, like, what does your flow look like?
How involved are you with, like, each project? Like, do you kinda, like, just shoot stuff off and kinda, like, come and look back? Or is it more of, like, a one-on-one experience? I'm, I'm interested to hear. I really like AI,
I, I really like AI. I, um, I get a
you said.
Um,
And, um,
I've recently switched to using the desktop apps
I, I've recently switched to using FFMPEG.
so I've, I've been using Codex desktop and, and Claude desktop. I really like them. Um, and, and I
I also make heavy use of, like, RevCloud
projects. Uh, AI code review is, is, is super handy.
Um, and, and I also-- I think something that, like, people ask me about a lot is, is-- So when I reply to having issues, I, I pretty much always do it through Claude. Uh, and I, I put a little, like, disclaimer on there just to let people know that it came from Claude because, like, you never know, right? But I do
But I do read it and,
know, so this
this is a-- I think people think that this is a lot of work, you
them, especially if it
what happens with the note. And this is
me. I,
of
I
my prompt in Claude. I read somebody that, you know, doesn't get people say that it's boring,
Um, because because it's,
just
it just has all this information in it that they just
an
go in and out really quickly.
And I think that's very true in the context of all of it. Uh,
even though it even though it might come across as like mechanic and I love people who respond to my stuff, right? Um, but, uh, I get I get like 1,000 GitHub notifications so so this this is is a really helpful way and it and me to me to respond to I people more. Um- yeah, and yeah, that-- think I think with projects like I've, I've, you know, like I, I don't I don't have any skills or anything. I have way more bugs than anything. My repo. Um, but open open source, the context is just that big. It's this with a big feeling of like, oh, I'm part of something. Mm-hmm. Um, um, so, these tools work well. And I think I think also make I make so much post, post like aI is aI is quite good at, you know, like a lot-- like I, I sure we've should recall her in like a few years, but I think about a sloth. Um, um, the the quality of PRs I get are extremely good. Like like I do get stuff and it's very rare once that those three or four people, like I get that I'm like, a PR that I'm like,
" This is
" This is crap." But like most of the most of the time good it's good quality. And you and takes some things might not be good and things, but, um, I think a lot of that is just that I write C lot and it's are a little strange.
Yeah, the, the Unix manifesto of do one thing and one thing well probably lends itself well to like an AI going, "Oh, well, what fits here and like what makes sense?" There's a
Justin: be said about Using the tools a lot for your own development too, and it like propagating the patterns that they're already sort of like good at. Um, I don't know, something interesting there. Cool.
[00:39:57] Mise Roadmap and OCI Services
Justin: Should we move on and talk about Meese? It's been a minute, uh, since we discussed it. Uh, and we've mentioned it a lot in this episode, not really like talked about in depth.
So maybe, uh, if you've listened this far and you don't know what it is, maybe we'll like give you a refresher on what it is. And then, uh, yeah, would love to, uh, hear some of like what are the latest things you've shipped and yeah.
Jeff: So Meez is quite mature. It's been around for almost four years now, and, um, the, the, the quick version of it is it's, it's a tool manager, manager, sort of like direnv, uh, and it also does tasks, sort of like Make or Just or Taskfile or things like that, but kinda all, in one. Uh, the tagline that I've kind of moved away from, but I always really liked, is the front end to your dev env. The sort of the idea is I, I would think that like a-- if, if you're, if you're it to its full extent, then like Meez is kind of the only thing you're talking to. Um, know, but that said, nervous to say it that way because I think the thing that Meez does well, that, that-- this was very intentional, is it's not a system in a way that or Buck2 or Bazel is.
It, it's, it's an overlay, is a better way to think of it. So like you can, you can adopt Meez and just use it to like run one task or install one tool or set one environment variable. It works great at that. You don't-- You can use it on top of Bazel. Works great. You don't need to go all in with it, you know. And, and generally what people find is like they'll say, "Oh, it works great for this," and then they'll use it for another use case, another use case. But like nowhere along that way is it saying like, "You gotta use Meez for everything." So yeah, I think that's, that's held true today,~~ I think. And I~~
Justin: something... Go ahead.
Jeff: for... Oh, uh, to answer your question about, like, what's come recently, I think the two, two biggest things I can think of is, one, experimental monorepo support. Um, monorepo support. It's still in experimental. but this solved a problem of, like, I want to run npm run test in a monorepo against a bunch of sub-projects, where each of those projects might use a different version of Node. Um, so you can do that now with this experimental support. the lock file was, was a huge challenge. Still a little bit hard, but that has come out of experimental and is working pretty well, I would say. it, it's hard for Mees 'cause Mees is not just one ecosystem, right? Like, if you write a, a lock file for, for Node, like, like op has, has one shape of dependency to worry about.
But Mees is compatible with pip, with GitHub releases, with, with, with SPM, with... and people can bring their own, right? So somebody wrote a Nix plugin for Mees, and so now it can do that. And so, like, all this stuff needs to integrate with the same lock file. Um, and, and that, that was really hard. It took me probably almost two years to get that out of experimental, but it's finally here now. And, uh, you know, that helps a lot with, I think two of the biggest problems that Mees has always faced and will always face. One is the GitHub token, which, which is, uh, you know, Mees does a lot of talking to the GitHub API, and the GitHub has very strict rate limits of 60 requests per hour. So basically it's unusable if, if you're not authenticated.
And getting that authenticated, it's not Mees' fault, but, like, if you're using it, it's the fact that mo- that's where most tools are. Um, and then the supply chain security stuff. You know, I've, I've tried to adopt everything I can from Sigstore to Cosign to, those are the same thing. But, uh, GitHub Provenance, you know. Basically, if, if a vendor offers a security feature, I want Mees to, to adopt it. And so from the user's perspective, they can just sort of trust that, like, Mees is gonna use the most secure way of making sure that the bits that are, that it's getting are they claim to be. and the lock file helps that 'cause it can sort of define, like, what those, what those rules are for that particular tool.
Justin: That's cool. Yeah, it's a hard-- seems like a really hard problem. Um, just, just that, like managing multiple tool versions. Uh, I will say I don't think I've run into the GitHub API rate limit very often, so I think you've done something there. Uh, I think I've hit it like once, but, um, yeah, that, that's, that's a really tricky one.
Uh, is that something that you've been thinking about of like, how do I You know, like, especially with, like, GitHub's, like, instability, that becomes like, you know, whether or not it's your fault, it, like, seems like, oh, this tool is, like, failing all the time 'cause of, like, not being able to install things, and it's like GitHub's, like, down again.
Yeah. Well, I-
Jeff: this is an opportunity for me, right? So that's one of the services that I wanna make is, is a proxy in front of that so that, so that you can have some security that you're getting isn't gonna rely on GitHub. Uh, but, um, yeah, I mean, I mean, I'd say, like if-- There's a website called mise-version.jdx.dev, and if you go there, you can actually go to the stats page and look at where things are coming from, and it's like 95%, I think, are coming from GitHub. and so yeah. I mean, that's where vendors are putting their stuff, and so it has to work right. You know? There's also, like, with GitHub, there's-- You have the API, and then you have the tarballs, and they're really like, um, completely different systems. The tarballs actually usually work all the time. It's very rare for that to go down. The API goes down all the time. And so this is where the lock file comes into play, 'cause the lock file puts the URL of the tarball so it doesn't have to resolve that, uh, when, when things go. So,
you know, my advice is if, if you're using Mise, you should, you should use lock file, 'cause it, it just bypasses a lot of the GitHub problems. And m- maybe it's not obvious that that would happen, but it works.
Justin: Cool.
Jeff: Uh, so is there anything else that's, like, left for you to build with Mees? It seems like you're kinda in maintenance mode and, like, just, like, shaking out all the bugs before you move on.
Justin: Yeah.
Jeff: Mostly, there's a story around dependencies. You know, so, so Mise does, you know, the dev tools, environments, tasks. I've always wondered if it could do dependencies too, you know? So like, this is very cool, but I don't know how useful it is. Uh, like, Mise could be this like polyglot package manager. So you could have like an npm package that depend on PyPI package. Now, I don't know why you'd want that, but I could build it. Um, you know, I, I am playing with dependencies 'cause they, 'cause going back to O where I was talking about the, the cargo model of like cargo run just like does the installs of everything. Like this is not just a Node problem, it's a problem sort of across everything.
And like where Mise really abstracts away the tool installs, the runtime installs, um, I think it could abstract away the dependency install too, so that you could, you could have that same experience no matter what language you're using. And so there's like a n- a new experimental part of the code base.
It was called Mies Prepare. I've renamed it to Mies Depths to really focus on dependencies here. that sort of does that, where it can, you know, run bundle install if it needs to run before running Ruby code, for example. definitely still playing with that. I don't-- I'm, like, probably 40% sure that I will, like, take that further than it is.
We'll see. But that's probably the biggest rock that, that I might embark on.
Yeah. And also secrets. I could see that maybe, maybe we do bring that back from F Nox. F Nox is kind of a test bed of me trying out ideas that I'm not quite ready to get into Mies, uh, around secrets, 'cause again, I haven't figured out the DX there. Um, and I think it's very possible if I did get F Nox to a state where I really liked it, then that maybe could come back into Mies. We'll see.
Justin: having FNOCs be separate is not necessarily bad just because it does, um... You can have, like, a different security posture and, you know, there's, there's, like, some opportunities there. Uh, and it also has a, you know, pretty broad surface area already, I think. Like, Mees getting larger is, you know, uh... It'd be one of the things to sort of, like, balance is, like, how much extra functionality to add.
I will say the dependency thing is just really interesting 'cause, like, so pretty much every Mees project that I set up, the first thing I do is add, like, a post-install hook, and that post-install hook will run the package manager installs for, like, whatever things that I'm using. So if it's a, you know, a Node project, it'll be like npm install on the post-install hook, and that'll be, like, the first thing that I do Recently been using it in a monorepo setting, and that's been interesting.
You like really some like cool features for monorepos, but monorepos are weird because you may have like a tool version that's like at the root, um, but you're like running something for a dependency and like Mizal at least make sure that the tools are installed, but like I can't use like a post-install hook there to...
I don't know. So that's like one of the areas where I'm like, I want some way to say like, "Hey, check that the dependencies are installed." Like, you know, or like a, a, a thing to, to say that is like, you know, 'cause it's like you-- at the end of the day, if you were trying to implement this for like all the package managers or something, you'd have to figure out like how do they all do checks and stuff.
But like if I had a, a way to say like, "Oh yeah, this kind of depends on this thing. Make sure, um, that, you know, this, these packages are installed." Uh, and lately I've been trying to use like a setup task, um, and like add that as a dependency to all the tasks and like use the... You have this like cool feature to like check if like something has changed, like, um, and that's been relatively helpful.
It's just like kind of verbose. Um, so it's like I'm still trying to figure, figure that one out, but maybe something there.
Jeff: Yeah. Yeah. It's, it's not a solved problem with, with Mies yet. Yeah. Um, but that's definitely an area I, I would like to tackle sure.
Justin, wa- wanna do the future question?
Justin: Um, sure. Yeah. Sounds good. Um, cool. So as we're wrapping up here, um, and sort of like reflecting on the, the things that you've built recently and, and thinking about the things that you've built in the past and you're, you know, exploring this new company, which is, which is so exciting. Um, what are you, like what are you thinking about next?
Like what's like up, you know, on top of your agenda? Uh, I know you're, uh, like working actively on Oob, so that's new and that's like, uh, an active development. You're still doing maintenance on a lot of the, the projects, but like what's the next thing for you?
Jeff: The, the services for Mies for sure. Yeah. and so like the-- th-this is still up in the air. I'm, I'm-- This is, this is a spike, but like right now it, it's sort of a cross between something like Artifactory or Nexus, but also like Docker hardened images. I found this-- Actually, a user pointed me to this really cool thing in OCI called OCI Distribution Spec. and it's, it's a way that you can use OCI to make things that are not containers. And in my case, I wanna make tools that I'm using OCI as a distribution method. And the reason I'm doing that is because OCI has all these really great, uh, security features and provenance checks, SBOMs, and like all this stuff is very standardized in the Docker container world. And so like I'm, I'm taking advantage of that to, to basically, uh, tools inside of these OCI containers that, It's really for companies that wanna have like a policy where they say like, "I want only tools that are this new, that passes all the provenance checks. We need SBOMs because if a CVE comes out, we wanna know like which computers were infected with that, with that CVE." Um, and so it, it, it's quite exciting. Um, that, that's like the biggest focus I have. Uh, and the other thing there is also like, uh, OCI is, is like so heavily used that like you can put ECR or Artifactory or like anything that can talk OCI as a proxy between me and that, and now all your tools are cached and very fast, uh, with, with sort of like commodity stuff that just needs to know how to talk OCI, which is so many things now.
Yeah.
Justin: Cool. Awesome. Um, so Andrew, you wanna wrap? Well, that wraps it up for my session. Thanks for coming on. I feel like having you out and your work on NextAuth was interesting and exciting and inspires people to go try new things. So thanks for coming on and talking about it. It was great.
Jeff: ~~Yeah. ~~Thanks for having me again. Really like
Justin: Yeah. Thanks, Jeff. Um, Misa's amazing.
I use it every day. Um, so I appreciate your work on it, and I wish you the best of luck on your new endeavor. Um, it's really exciting to have someone else trying to make open source sustainable and I, yeah, um, hope for your success.
Jeff: Thanks so much, guys.
