NPM Packages with Monarch Wadia

Episode Description

Anthony and Monarch walk through publishing an npm package from scratch, exploring pnpm workspaces, the exports field, CLI tools, and GitHub Actions.

Episode Summary

In this episode of AJC Web Devs, Anthony Campolo and returning guest Monarch Wadia tackle the often-intimidating process of publishing to npm. Monarch introduces his open-source library Ragged, a lightweight wrapper for large language models, and uses it as a concrete example to walk through the key decisions involved in npm publishing. The conversation covers the distinction between npm and git, how the exports field in package.json defines a package's public API, and why getting exports right is harder than the actual publish command. They discuss pnpm workspaces for monorepo management, semver versioning strategies, and how GitHub Actions can automate both documentation deployment and npm publishing with auth tokens. Along the way, they compare CLI-building libraries Commander and Yargs, touch on the Microsoft ownership chain connecting npm, GitHub, TypeScript, and VS Code, and take a memorable detour into how hardware drivers bridge analog voltage and digital software. The episode culminates in a live demo where Anthony creates a brand-new npm package, publishes it, and Monarch installs and runs it on his machine within minutes, proving that the initial publish is simple even if the long-term polish takes time.

Chapters

00:00:00 - Introductions and the Ragged Project

Anthony welcomes back Monarch Wadia, who introduces himself as a full-stack developer building Ragged, an open-source library that provides a simple, standardized wrapper around large language models for JavaScript developers. He mentions the project just received its first external pull request and invites contributors of all skill levels to get involved with documentation, examples, and code.

Monarch also shares that he's actively looking for work, highlighting his 12-plus years of experience building products from scratch and managing teams. The conversation then pivots to the episode's main topic: how to publish a package to npm, which Anthony describes as a major gap in his own knowledge and a rite of passage that many developers find surprisingly under-documented.

00:03:44 - The Basics of npm Publishing and Semver

Monarch explains that the actual act of publishing to npm is straightforward — just running npm publish with a valid package.json — but the real challenge is ensuring the package works correctly on other people's machines. He describes how the most organic way to catch issues early is simply having friends try to install and use the package, noting that for projects with zero users, the risk of breaking things is negligible.

The discussion moves into semver versioning, where Monarch describes his approach of manually incrementing patch versions in package.json before each publish. Anthony draws on his experience following the Redwood framework's versioning over several years to explain the significance of major, minor, and patch versions. They briefly touch on Changesets, an automation tool for version management, which Monarch finds interesting but hasn't adopted yet given Ragged's early stage.

00:10:23 - Exploring the Ragged Monorepo Structure

Monarch shares his screen to walk through Ragged's project structure, which is organized as a pnpm workspace containing the main library, a Docusaurus documentation site, and several example projects. Anthony highlights that choosing pnpm is a meaningful decision, contrasting it with yarn and npm based on his own history with each tool, and noting that pnpm is particularly strong for monorepo workflows.

They discuss the tradeoffs of different workspace tooling, including VS Code workspaces, which Monarch finds unnecessary for a project of this size. The conversation also touches on where automation belongs — Monarch prefers GitHub Actions over editor-level tooling, using it to deploy both Docusaurus documentation and npm packages automatically.

00:15:17 - npm vs Git, Package.json Deep Dive, and Security

Monarch makes the important distinction that npm is completely independent from GitHub — you don't need a repository to publish, and what's on npm may differ from what's in the repo. Anthony underscores the security implications of this, pointing out that anyone can push arbitrary code to npm with no guarantees about what you're downloading. They examine Ragged's package.json, which is notably minimal with very few dependencies.

The discussion covers peer dependencies like OpenAI and RxJS, Monarch's plans to make the OpenAI driver optional for alternative providers, and the abstract driver interface that enables extensibility. They also look at the root-level package.json versus the library-level one, noting details like license fields and how npm reads package metadata independently from GitHub.

00:23:36 - GitHub Actions for npm Publishing

Monarch walks through his GitHub Actions workflow for publishing Ragged to npm, starting with the basics of how Actions trigger on pushes to the main branch. The workflow runs on an Ubuntu machine, checks out the code, sets up Node 20, installs dependencies with caching for faster builds, runs the build step, and finally executes npm publish using an auth token stored in GitHub Actions secrets.

Anthony explains how the shared Microsoft ownership of npm and GitHub makes this integration smoother. The conversation briefly detours into WSL 2, with Monarch praising its seamless Linux-on-Windows experience and Anthony relaying mixed reports about file system performance. A viewer question about drivers leads to an extended but entertaining explanation of how hardware drivers bridge physical voltage signals and digital software.

00:31:04 - Hardware, Drivers, and the History of Software

Monarch illustrates the concept of drivers using a thought experiment about a simple 16-bit computer with Lego-brick-sized components, explaining how raw voltage in a wire corresponds to binary values and how software reads those values through layers of abstraction. He walks through how early computers required physically wiring together logic before software automation replaced that process.

Anthony connects this to vacuum tubes and transistors, noting the progression from analog hardware to digital abstraction. The tangent provides a surprisingly grounded explanation of how all computing ultimately interfaces between analog signals and digital variables. They acknowledge the detour and steer back toward the practical npm publishing workflow, with Monarch preparing to demonstrate the actual publish command.

00:37:05 - The Exports Field and Building a CLI

Returning to npm mechanics, Monarch explains that the exports field in package.json has replaced the older main field approach, allowing package authors to define exactly what consumers can import. He admits spending two days working through exports configuration and partially simplifying his approach out of frustration. The exports field controls the public API surface, supports different module formats like CommonJS and ES modules, and prevents consumers from depending on internal implementation details.

Anthony then asks about CLI tooling, and Monarch recommends Commander over Yargs for its simplicity and ease of use. They walk through a typical Commander program structure with commands, options, and handlers. Anthony shares his earlier attempt at building a CLI with Yargs and ChatGPT, outlining the three core features he wants: processing playlists, single videos, and arbitrary URL lists. They also examine the bin field in package.json, which is how npm packages expose CLI commands globally.

00:50:05 - Live Publishing a New npm Package

Anthony and Monarch decide to create and publish a brand-new npm package from scratch on stream. They initialize a new project called autogen-ajc, create a minimal index.js with a console.log, and walk through the npm authentication process including account creation and two-factor authentication. Within minutes, Anthony successfully runs npm publish and the package appears on the npm registry.

Monarch immediately installs the package on his own machine and runs it, confirming it works — making him the package's first user. They briefly discuss next steps including adding the bin field for CLI support and the challenges of wrapping C++ tools like Whisper in a Node package. The episode wraps with plans to continue weekly sessions, potentially integrating Ragged's LLM capabilities with Anthony's auto-generation tool, and both share their social links for viewers to follow along.

Transcript

00:00:02 - Anthony Campolo

Okay, hello everyone. Welcome back to AJC and the Web Devs. We got returning guests now. Monarch. What do you think? If anyone saw you last week, they probably already know who you are. Why don't you introduce yourself anyway?

00:00:16 - Monarch Wadia

Sure. So I'm a full stack web developer. I like hacking away on TypeScript and Python. These days I'm building a library called Ragged. Ragged is a simple wrapper for large language models so that you can bring AI into your front end and your back end really easily. I'm trying to make it so that everything is very standardized and it's a community project, so there's a few different people working on it right now.

It's early stages. We just got our first pull request from a contributor that I have to review now and merge in. So yeah, we're version 0.2. If anybody's interested in AI and large language models and they're more of a web developer or even a junior developer, then there's plenty of room for documentation writing, writing examples, and contributing to the community. We're open to contributors.

[00:01:12] The other thing is that I'm also looking for work. So if anybody wants someone with 12 plus years of experience managing teams, running their own startups, a self-starter, quote unquote, entrepreneurial drive, quote unquote. Basically, I can make stuff happen and build stuff and deploy stuff. I've built plenty of apps on my own from zero to one. So if anybody's looking for someone like me, I'm super open to it. I'm also open to larger companies.

But anyway, that's my little plug. Hire me. Give me money. Coming back to Ragged and the topic today. Anthony, I guess the topic is how to publish to npm.

00:01:55 - Anthony Campolo

Yeah, exactly. Because you were kind of suggesting to me at the end of our last episode, hello Fuzzy Bear, that you felt like I should take my show note auto generating thing to the next level. And one of the things that would entail, we were kind of chatting about it in messages afterwards, would be just making it an npm CLI you could just install and then you can kind of work it into your JavaScript projects a little easier. It wouldn't just be this giant bash script you would have to deal with anymore.

I've had these thoughts as I've been building this, that once I got it to just the functionality I wanted, then how can I turn it into this other kind of thing? I did try and build a full Node version and got pretty close, but didn't quite make it work entirely the way I wanted it to, so I ended up kind of reverting back to just the bash script.

[00:02:48] But you're in the middle of building this project and you're publishing to npm, and it's something that kind of feels like a huge gap in my knowledge. It's like a rite of passage as we see here. "Oh, publishing to npm. Fun." This is a great way to put it, because everyone I know who's done it has said it's very challenging. And then they're always asking, where can I find a template? Where can I find resources? Who is actually creating content explaining how to do this? And it's pretty sparse.

So hopefully this conversation we have here will actually end up being a useful resource for people. You don't do it the first time. Yeah, I mean exactly. I'm not even expecting to have anything published by the end of this. This is kind of more of like setting out what it is, how you did it, and what resources you used or didn't, whether you were just straight up npm CLI is all you need, or who knows.

[00:03:39] So feel free to kind of talk about your own experience with it right now.

00:03:44 - Monarch Wadia

Awesome. Yeah, okay. So I'll just hop into it. So publishing to npm, publish it to JSR. Okay.

00:03:54 - Anthony Campolo

Deno's npm competitor.

00:03:57 - Monarch Wadia

Ah, gotcha. I have never used Deno, although I've heard great things about it. So good to know that JSR is like npm for Deno.

My first ever npm package was MKR Component. Okay, cool. So when you publish, you are basically pushing a bunch of code to npm and then that gets registered against npm. That part is super easy. You can do that on a simple hello world, as long as you have a package.json and a few fields like the main file and stuff like that defined.

Pushing to npm is actually one command. It's just npm publish and then you put in the name of the package. So publishing is not the hard part. The hard part is to make sure that it works after you publish it on somebody else's machine.

00:04:48 - Anthony Campolo

Right. Which is a hard thing to test because you need a separate machine or a friend, basically.

00:04:55 - Monarch Wadia

Yeah. In my case, it was people who wanted to try out the project, and they started working on it on their local. So they would message me. I think you tried it out, and you were like, "Hey Monarch, this thing is broken. What's happening?" I was like, "Oh crap." Okay, so I went and I fixed it really quickly. And then the next day I pushed it and I asked you, "Hey, can you try it again?" And it worked.

So that's really the most natural, organic way to test it is just get your friends or people you know to use it. And then if it breaks, then you know that it's broken. Sort of feels weird, right? Because we're always told, don't test in production. But really, it's about risk management.

[00:05:40] What's the risk of breaking a package that nobody uses? It's zero. So I think the easiest way to just do it is to just do it through trial and error, and not worry about breaking stuff or doing it wrong the first time, because npm is very forgiving.

If you're using semver and you're just incrementing patch versions, that's all you need to do to publish a package is increment the patch version, which is like the 0.0.x part, the x is the patch version. And as long as you have no users in the beginning, you can solve those early publishing problems without any issues.

Now, if you already have a package published and you're changing the build process, it gets a little trickier at that point. So maybe you want to publish it to a private repo. I think there are npm replacements, like private repos out there. So maybe you want to publish it like that.

[00:06:39] There's different ways to deal with it. You can npm install from a directory on your local, so there are different ways to test and deal with it. But really, that's not the hard problem. The hard problem is making sure that your exports are set correctly. So I can get into that while we build it out. Do you want to do this together on your local? Do you want to do it on mine?

00:07:09 - Anthony Campolo

Would you be willing to show some of the Ragged stuff that you've done? And we can look at that first, and then we can switch to mine and kind of see where we want to go from there.

00:07:19 - Monarch Wadia

Yeah, for sure.

00:07:22 - Anthony Campolo

So okay. Are we recommending Changesets in semver out of the box? So I do know what these things are to a certain extent. This is just kind of like if you want to build in processes so that as you get more contributors who are pushing more stuff, you have a clearer idea of what's changing and what's not, essentially. Right?

00:07:43 - Monarch Wadia

Yeah. I'm not recommending Changesets. I had to go look up Changesets immediately. I didn't know what Changesets is. But this looks super useful. It's awesome.

00:07:52 - Anthony Campolo

You'll see this for probably like Redwood, like really big projects. This stuff is really important. And I was actually, as you were saying the last couple things, kind of thinking about this, because this was where I first learned a lot of this stuff, just being a user.

Redwood was a project that I followed version by version for a very long time. So I would see when there would be minor versions and then that would take a year and a half to do major versions. And then when stuff breaks you do the patch version.

This is Tom, like Tom wrote the first semver kind of explanation. So for him he was always very clear about this. This is the way you do it. You have major versions and then if stuff breaks, you have to do another major version. Otherwise you do minor versions, just build new features, and then when there's an actual patch fix, then you need to do it in the third one.

[00:08:43] So that was always really useful just for me to live that process for like a year and kind of just embed it in, because some people will just increment numbers and not really think about it, I think.

00:08:56 - Monarch Wadia

Yeah. I'm just doing semver for the version, like the version string in semver format, and I'm just manually incrementing them. But Changesets is cool. Changesets is this library that lets you automatically increment versions and stuff, which looks interesting, but I'm not using that or anything automated.

What I do is I just increment the version manually in package.json before I push, and that's how I'm doing it. So I can walk you guys through how I'm doing it in Ragged, and I'm open to feedback and critique because it's not going to be perfect.

It's working right now, and there's a bunch of limitations, like none of the version pushes are really documenting all of the changesets right now. And that's going to be a bit of a pain in the beginning too, because we're just changing right now. It's in the "expect your API to break" phase.

00:09:56 - Anthony Campolo

So you have a big disclaimer on your README at the top just saying, this is in beta, this is not production ready, this will change and break at any moment. As long as you just kind of make that very explicit at the top, people can kind of live with that.

00:10:10 - Monarch Wadia

Totally. I've been working on documentation, so I have to figure out how to add that warning as a template. But right now I've added monitoring.

00:10:22 - Anthony Campolo

Like...

00:10:23 - Monarch Wadia

Yeah man, I'm a cowboy. So let me share my screen. Where's my screen?

00:10:33 - Anthony Campolo

Yeah. And if you don't know, Fuzzy Bear, he used to be involved, still is involved, but he used to work for Astro and now works for the Linux Foundation.

00:10:42 - Monarch Wadia

Ah, wow. Very cool. Nice to meet you.

00:10:46 - Anthony Campolo

Okay, let me know when I should add your screen to the thing.

00:10:50 - Monarch Wadia

You can add it now. Thank you for asking.

00:10:53 - Anthony Campolo

Yep.

00:10:56 - Monarch Wadia

Awesome. So here is Ragged. Ragged is a pnpm workspace.

00:11:05 - Anthony Campolo

Bump up your font a few times just for your editor. Yeah.

00:11:07 - Monarch Wadia

Mm.

00:11:08 - Anthony Campolo

Bump up your font a few times just for your editor. Yeah.

00:11:12 - Monarch Wadia

For sure. There you go. Okay. So Ragged is a pnpm workspace, and it has the main package which is here. Then it has documentation which is here, and then it has a bunch of examples which are all in examples.

00:11:32 - Anthony Campolo

Okay. Yeah. Let's stop right here because this is great. So pnpm is kind of required for what you're doing because you're specifically using their workspaces, which would be different if you're using, say, yarn.

00:11:46 - Monarch Wadia

Exactly. And people who are using Ragged, they don't have to care about this. This is just if you're developing on Ragged, then yeah, you need pnpm.

00:11:54 - Anthony Campolo

Yeah. So these are the decisions I'm going to have to make right now. So that's why I'm honing in on these things. So back to Redwood. Redwood is and has been yarn only forever. And so I used yarn for like 2020 to 2022 or so, and it was the only thing I used.

And then eventually pnpm came around and was just what people thought was way better. And a lot of people who had been using yarn kind of moved back to npm. Yarn has kind of become less and less of a viable option, I think, over the years. It still works, you can use it, but it just doesn't really seem like the right decision for a lot of reasons.

I went back to npm because I just found that I use things like Volta, which can be kind of weird with pnpm. That's my node manager instead of nvm. And just other stuff, but for workspaces and stuff like this, that didn't even exist in npm for a while.

[00:12:55] Now it does. But I've heard that this is where pnpm really shines, for this kind of stuff.

00:13:01 - Monarch Wadia

Yeah, I haven't plumbed its depths for all of its intricacies, but the feeling I'm getting is that it's like npm, but it's faster like yarn because it caches packages. And it also has little utilities like pnpm -r, which recursively can run a command across all of your packages. So it's a lot better for monorepos is what it looks like.

00:13:35 - Anthony Campolo

Exactly. Yeah.

00:13:37 - Monarch Wadia

So shall we move on? Should I explain how we're publishing?

00:13:42 - Anthony Campolo

Let's see. I got two tool recommendations for this point. VS Code workspaces on top of pnpm workspaces. I'm not sure if you know anything about VS Code workspaces.

00:13:52 - Monarch Wadia

I do. I'm not using it because it just feels like for this project, it's not super necessary because the only important thing is really Ragged, which is the main folder. And the other things, I just go through my CLI and do pnpm.

00:14:12 - Anthony Campolo

I'm sure that I know VS Code workspaces are okay. Or is that just me? Like, literally when you have a specific workspace with specific settings. I don't usually use that in general, but I think I know what you're talking about.

00:14:27 - Monarch Wadia

Yeah, that's the thing. That's the exact thing. I find it a little clunky and a little onerous. It's worth it for projects of a certain size, but for a project of this size, personally, I'm just going into the CLI and doing all the commands manually. I don't even use the run and debug, I just do it from the CLI. That's just my workflow.

00:14:52 - Anthony Campolo

And I feel like once you want to build in more automations and stuff like that, I would want to do that at a GitHub Actions level. Not necessarily at my editor level.

00:15:05 - Monarch Wadia

Yeah, there's GitHub Actions built into this too.

00:15:08 - Anthony Campolo

So yeah.

00:15:10 - Monarch Wadia

I'm using it to deploy Docusaurus and npm publish.

00:15:14 - Anthony Campolo

So then your docs stay in sync with everything.

00:15:17 - Monarch Wadia

Exactly. Now one thing about npm and git is that people often conflate the two because they think that just because there's a URL on the npm site. So if I go, just to make this more concrete, if I go to Ragged's npm page and I look at the pretty standard quickstart, link to documentation. If I go here and I look in this section, there's the repository here.

Because of this link, a lot of people think that you get exactly what you see, that the exact version that's on GitHub is what gets published to npm. But that's not the case. How it works is npm is totally independent from GitHub. You don't even need a repository to publish to npm. You can publish it right from your CLI without any git.

00:16:19 - Anthony Campolo

Which also makes it a freaking security nightmare because anyone can push any code anytime they want. You got no guarantees. You can't see the code, you're just going to download it to your machine and run it and pray to God. It's absolutely insane that this is what we do day to day.

But we got a comment here. "Tooling and control of each environment is crucial from dev to prod. This goes for shared environments." Yeah, absolutely. And this is what I like about scrappy open source stuff, is that you can kind of just get something working. And as long as you feel like it's going to be comprehensible to other devs, then they can kind of figure it out.

But I imagine at one point, if you do want to make this legit, you'll start building some of these higher level things that you're talking about.

00:17:04 - Monarch Wadia

Yep, for sure. Like it says, zero dependencies and zero dependents because that's what goes off. That's package.json that npm is reading. So npm will read package.json, but it won't go and actually read your GitHub because it doesn't care.

00:17:22 - Anthony Campolo

Can we see the package.json you do have with the actual dependencies? I'm curious.

00:17:26 - Monarch Wadia

Yes. So all of it comes from the Ragged folder. So this is the terminal. Yeah, sure.

00:17:39 - Anthony Campolo

Just for this section.

00:17:41 - Monarch Wadia

Absolutely.

00:17:42 - Anthony Campolo

All right. Fuzzy Bear says we gotta check out Devbox. So we'll put a pin in this and check it out in a second.

00:17:49 - Monarch Wadia

So this is my package.json. And here are the dependencies. So I have a couple of peer dependencies. Wow.

00:17:55 - Anthony Campolo

This is like nothing. This is such a tiny library.

00:18:00 - Monarch Wadia

Yes. [00:18:00] - Anthony Campolo It's incredible. It's really nice how little is happening here. I can look at this and it feels very comprehensible to me. I look at some open source things and it's like 50 libraries, just some insane number. It's all this stuff I've never heard of. And they got like nine ESLint configs and I'm just like, my God.

00:18:21 - Monarch Wadia

Yes, I have like one, two, three ESLint configs. I only have three. Yes, it's a nightmare. It's crazy what we do on a day to day basis, but yeah, this is how it works.

So peer dependencies. I'm going to take out RxJS at some point because I don't really need RxJS. It's just part of the API now. But honestly, I can take this out at some point. OpenAI, I'm probably going to take that out sooner rather than later. But OpenAI is kind of just there because...

00:19:02 - Anthony Campolo

Are you going to...

00:19:02 - Monarch Wadia

Build that...

00:19:03 - Anthony Campolo

Kind of a wrapper to access the OpenAI API?

00:19:07 - Monarch Wadia

I don't want to do that. Exactly. So the only reason this exists is because I don't want to do that and because all the drivers are just built into Ragged right now.

00:19:17 - Anthony Campolo

Right. But you're saying you're going to take it out. So do you plan to build that out?

00:19:21 - Monarch Wadia

I think the official OpenAI driver for Ragged is always going to have OpenAI as a dependency. Unless there's...

00:19:29 - Anthony Campolo

It won't be. But you can make it so it's not necessarily required if you want to use a different provider at some point.

00:19:35 - Monarch Wadia

Yeah, exactly. So it's already there. It's just I have to change how the constructor takes the object. Right now I have to... there's some stuff to do on the dependency resolution side. Like which exact driver are we using? That's the only thing that's stopping me.

But it's a new project. The only official driver right now is OpenAI, and nobody's using it, so it's not urgent that I have to support custom drivers. But custom drivers are already easily added. We already have an abstract Ragged driver, and this is the interface where you can just build the driver. So theoretically, it should be possible for anybody to pull this in as a dev dependency and build off of abstract Ragged driver.

00:20:26 - Anthony Campolo

Cool.

00:20:26 - Monarch Wadia

I don't know if any of that made sense. It sounded like technobabble, even to me.

00:20:31 - Anthony Campolo

Yeah, no, it's all good. Still thinking kind of high level here. So let's take a look at the documentation or the examples, the other high level directories that aren't Ragged right now.

So documentation, examples. The documentation is just going to be a Docusaurus site. That's kind of like any sort of static site generator you can plop in here. Like you could have an Astro project here instead of a Docusaurus project. Right?

00:20:58 - Monarch Wadia

Correct.

00:20:58 - Anthony Campolo

That's probably what I'll do, because actually I do like Docusaurus a lot, and I've used it a bunch, but I'll probably end up plopping Astro in because I've already built out somewhat of an integration. I did this with Ben Holmes on his stream, where the output of Autogen, because it creates a markdown file like I was showing last time, and then you just have that set up with an Astro content collection which defines all of your front matter basically with Zod.

So you can make your front matter typesafe so it can make sure you have a correct date and stuff like that. And you can have, say, your description needs to be a certain amount of characters, and then it'll break your build if your front matter doesn't conform to these certain things. So the markdown it spits out can be matched with that. That's kind of a thing I'm thinking about where you're going to have an output of a website almost from the tool itself.

00:21:53 - Monarch Wadia

Yeah, I use Jekyll for my blog. Jekyll is just so elegant and simple. I just really like it. And you could use Jekyll. You could even just use HTML files.

00:22:10 - Anthony Campolo

Yeah. Astro Starlight is specifically... The Astro team has basically been building a kind of higher level Astro library which is specifically for documentation, and it does all sorts of nice stuff for you. Like if you're going to have multiple languages, you can switch tabs. It does all these really nice git diffing highlights. It's super sweet. I've been slowly building in some of those features into my Astro blog, just piece by piece.

But yeah, this is a little bit off topic. I'm all about the static site generator. So this is the deploy step, which is basically just installing directories, doing a build, and then setting up pages with configure pages.

00:22:54 - Monarch Wadia

This is just configuring GitHub.

00:22:56 - Anthony Campolo

Because this is the GitHub Pages. That's right. Yeah.

00:22:59 - Monarch Wadia

And then upload pages artifact just pushes your static assets to GitHub Pages. And you have to specify where. So I've configured my Docusaurus to build inside the build directory. I think it might be set up like that just out of the box.

So first thing it'll do is it'll build in GitHub Actions. Then it'll take the build folder and deploy that to GitHub Pages. Really simple. Not much to see here. It's really boring actually. The npm publish might be more on topic, and maybe I should just show you how I'm doing that.

00:23:36 - Anthony Campolo

Yeah, a little more complicated. Just for this section, why don't you close your left side of your editor, the file directory, and then you can bump up one on your font?

00:23:48 - Monarch Wadia

Aha.

00:23:49 - Anthony Campolo

That's perfect. Yeah.

00:23:51 - Monarch Wadia

Awesome. Okay, so this one is for publishing Ragged to npmjs.

00:24:00 - Anthony Campolo

And just for anyone, go up to the very top actually. Just because I know some people, if they're really noobs, they've never even seen this before. So this is a GitHub Action, which is like the coolest technology once you actually learn it.

Basically what's happening here is when you push to branch main, a thing is going to happen. That's why it says "on push branches main." And this is where you could build in other type stuff if you wanted to have like a preview branch. Right? And then "jobs" is where the actual build is happening. So here is where you have to explain what's actually happening for me.

00:24:40 - Monarch Wadia

Yep. So it runs on an Ubuntu box. It's more or less like WSL or Linux. It's a Linux machine that runs, and it does a bunch of setup. Honestly, a lot of this is just boilerplate stuff that...

00:25:04 - Anthony Campolo

Is setting the Node version. So if you want to have specific Node features, you need to make sure you're using the right Node version.

00:25:12 - Monarch Wadia

Yep. It's checking out the main branch here, I'm guessing, because it says "check out a git repo." And then it uses "setup node," so setting up Node with version 20.x. Then it's installing npm. Then it's getting the npm store directory. This is just boilerplate. This saves a bunch of build time because it caches all the node modules that it downloads so it doesn't have to download them over and over again. It just goes to the cache and pulls them out.

So this enables that for npm, sets it up, sets up cache for npm. We're still in npm. Now it does the install finally here. Now we're in... not even actually, this is like copying a documentation page for some reason, which I can get into. But then you do npm build. Now finally, after everything is built, then what this does is npm publish inside the Ragged directory with an auth token which has been provided to GitHub Actions.

[00:26:22] So in the GitHub Actions dashboard on the browser, I gave it an npm token and that lets GitHub Actions act on my behalf to publish. So if I do npm publish on my local machine, I have to log in before I can do npm publish. This is the same as logging in on the GitHub Action side.

00:26:47 - Anthony Campolo

This is one of the nice things about the fact that npm and GitHub are owned by the same company.

00:26:52 - Monarch Wadia

Now, is npm owned by Microsoft?

00:26:55 - Anthony Campolo

npm is owned by GitHub, which is owned by Microsoft, I think is how that structure ended up happening. Or maybe Microsoft just bought npm. But it's all under the same corporate structure now. It has been for a couple of years.

00:27:09 - Monarch Wadia

Wow. So we're all just Microsoft developers. Awesome. TypeScript is owned by Microsoft too. So is VS Code.

00:27:16 - Anthony Campolo

Yeah, it's pretty nuts. And they're the ones who partner with OpenAI.

00:27:21 - Monarch Wadia

Yeah. And I'm running this on Windows.

00:27:24 - Anthony Campolo

So that's where you got me. I don't run Windows.

00:27:29 - Monarch Wadia

You know what? Neither did I until I realized WSL is seamless.

00:27:34 - Anthony Campolo

Oh, really? Okay.

00:27:35 - Monarch Wadia

Oh, yeah. Best developer experience. It's shocking.

00:27:41 - Anthony Campolo

I've heard bad things, but I feel like that was before. There's WSL 1 and now you're on WSL 2. It's like a whole different ball game. So yeah, I have heard since they actually made it work correctly, it's been really nice.

00:27:56 - Monarch Wadia

WSL 2 supports Windows integration. WSL 1 didn't support that, so you can't really see what's happening in WSL 1. It's all just the terminal. But they have that now. So if you open up a graphics application or a game inside the Linux side, it'll actually render that in a window on your Windows side. So you can actually see what's happening. It's seamless basically.

00:28:24 - Anthony Campolo

So someone's asking if WSL 2 is slow with files still.

00:28:29 - Monarch Wadia

Really? I did not notice that.

00:28:34 - Anthony Campolo

Yeah, it may be that certain machines just behave different ways. If they're old enough then you can have issues. And maybe if you're running certain workloads it can be faster. So it's like saying an operating system is slow or fast is just not high resolution enough, I think. So I don't know, maybe for whatever you're doing, it's not so bad. Who knows.

00:28:57 - Monarch Wadia

Gotcha. I'm a Linux guy, so I'm just happy that I can have my Linux and also play video games. That's me. Also, it's nice because I don't have to worry about driver issues with, say, CUDA, because I'm learning CUDA and I'm working with that here.

00:29:15 - Anthony Campolo

They say it has something to do with drivers, which I don't know. I couldn't even tell you what a driver is, really. It's a thing you plug into a computer to do something, I don't know.

00:29:26 - Monarch Wadia

A driver is, when there's two physical devices, you have to wire them up with copper wires going through them. A driver is the software that converts the physical signals into digital data. Basically, it's software that converts that stuff into something that can be used.

Now, it doesn't have to be hardware at the bottom. It can just be a lower level hardware item. A driver doesn't...

00:29:59 - Anthony Campolo

Doesn't have to be like plugging in a CD-ROM drive or something. It can just be a thing that's already built into your computer.

00:30:05 - Monarch Wadia

Yeah. So the CD-ROM drive is a physical thing, but even if it's built into your computer, it'll have a driver on the host side that makes sense of the data that's coming from the hardware. Does that make sense?

00:30:24 - Anthony Campolo

It does. I've never gotten deep enough into hardware to where I have a large enough mental frame and knowledge tree to where I can hang on something specific that I've ever done.

Not necessarily that, but what you said made sense because I think the problem why drivers get confusing for me is that I feel like the computer has abstracted more and more physical things, and almost everything just runs over Wi-Fi. I plug in an HDMI cable sometimes to my computer, but that's pretty much it. Or power, or my phone. So I guess those probably all involve drivers in some respect. But anyway, this is super off topic. So let's get back to that stuff.

00:31:04 - Monarch Wadia

Sure, whatever you want. I was just going to give you a really simple example just to drive home.

00:31:09 - Anthony Campolo

Yeah. Drive home.

00:31:11 - Monarch Wadia

Ha ha ha. Let's say you have 16 bits of RAM. Super underpowered computer. So you have 0000 and you have 16 bits of RAM, and that's all you have.

These are all, because it's such a simple computer, let's just say it's like the size of an average Lego toy, like a Lego castle. So you can actually imagine all of these are the size of Lego bricks. They're copper wires, but they're the size of Lego bricks. So you can actually touch them and zap yourself, right?

So if you think about it, the difference between a zero and a one is really the difference between the voltage that's running through a wire. Right?

00:31:59 - Anthony Campolo

Yeah, I know this stuff. Yeah.

00:32:02 - Monarch Wadia

Right. So on the software side, you can write code where it's like "get RAM at..." And I can't remember the C/C++ commands for this. But if you can "get RAM at 1, 2," which is the coordinate of this guy, then on the software side, "const val," which is a bool, is "get RAM at 1, 2." And that will get you either 1 or 0 depending on the voltage amount in the wire.

So if I physically went in here and hooked that up to a light switch and I could flip the switch on and off, then I could flip the actual value of the RAM cell by turning a physical switch on and off. Because if I turn the switch off on my wall, or maybe it's a little circuit that I've built...

[00:33:06] If I turn the switch on and off, that value flips from 0 to 1. Now, this code of yours, how does it know whether it's 0 or 1? Well, at some point there's some lower level of abstraction that goes in and reads that 0 or 1 and gets the actual voltage, for lack of a better word, and converts it into a 0 or 1. And that can be done either on the hardware side or the software side, depending on your architecture.

00:33:36 - Anthony Campolo

I've been going through a compiler and interpreter and all that stuff.

00:33:40 - Monarch Wadia

Sure. I mean, those are words. So yeah, like we could say compiler, interpreter.

00:33:45 - Anthony Campolo

You said "this code," which is written in a language.

00:33:48 - Monarch Wadia

Okay, fine, fine. How it would actually work.

00:33:53 - Anthony Campolo

I'm vibing with this. I understand what you're saying.

00:33:56 - Monarch Wadia

Okay. Well, how would it actually work is you would have a hardware component that outputs... some sort of hardware component where the input will be raw voltage and the output will be either off or on. That's the output. Off would be zero, on equals one. And that's the actual output that this hardware component gives you.

That hardware component gets fed into a register in RAM. So if this is just raw, hardwired, very basic computers back in the early 50s or 60s, then you would just read that output directly from RAM right from here. And you'd probably be wiring together the code instead of writing a compiler for it.

So instead of wiring together the code, at some point somebody realized, well, instead of wiring stuff together, I can just write some sort of software that can automate that process for me. And then stuff sort of started turning into digital rather than physical.

[00:35:08] That was the original interface between digital and physical. We have all these analog systems that have raw voltage and we want to turn those into variables. So how do we turn raw voltage into variables? And that's the history of software engineering.

00:35:21 - Anthony Campolo

Because that's what the tubes were. Vacuum tubes, right?

00:35:27 - Monarch Wadia

I don't know enough about that, but...

00:35:29 - Anthony Campolo

Vacuum tubes are basically like a light bulb that's representing the on and off, which is a raw voltage.

00:35:36 - Monarch Wadia

Gotcha. Yeah. That sounds right.

00:35:38 - Anthony Campolo

Yeah. Because vacuum tubes preceded the transistor. The transistor is what replaced the vacuum tubes.

00:35:45 - Monarch Wadia

Gotcha. It's all analog. It's just we've been fooled into thinking it's digital.

00:35:51 - Anthony Campolo

Fascinating. There's your lesson for the day, kids.

00:35:56 - Monarch Wadia

Back on topic. I should probably get into the npm publish. So this npm publish will just push it to npm. There's not much going on here. I think if I tried, I could probably find an actual live npm publish command, if I'm lucky. Maybe not.

But this is the npm publish command, and all I have to do is, if I'm in the directory, I do npm publish. It'll try to publish it and it'll fail because I haven't incremented the version. And then it'll ask me to authenticate my account because I'm not authenticated. When I do npm publish, it'll ask me to publish it to the registry. And then I'll have to log in and stuff. But I'm not going to do that.

[00:37:05] But that's how the workflow works. You authenticate your CLI and you can just publish right from your CLI. You don't need GitHub Actions or anything like that. So you can just publish directly from the CLI. And there's plenty of tutorials on how to publish.

The one gotcha that I found was that I wanted to publish... so this is a full stack app. The old fashioned way of doing it would be "main" and then I point to a JS file or something like that. That's the old fashioned way of pointing at the entry file. So if you do "import Ragged" then what you're actually importing is the contents of that file. But that's the old fashioned way of doing things, because that doesn't support all the different packaging options that we have now. So instead of that, "exports" is kind of the new way of doing "main."

[00:38:07] Learning how exports works is really important because I spent probably two days just trying to figure out exactly how to publish to npm without breaking stuff. And to be honest, I halfway just gave up and did something less complicated than I wanted to do.

So you can do stuff like export for Node and then export for CommonJS. And then there's stuff for types, and you can define all of your types. You can also define what happens if... How do I explain this? This is the convention that exposes the public interface for the package to the people who are downloading it. They'll only be able to see what you expose here. They shouldn't be able to see anything that you don't expose.

So you define your entire import structure inside exports. And that's super important if you want to give a really good developer experience, because you don't want people to just be able to import everything. You want to give them the stuff that's relevant so that they don't depend on internals, because your internals are going to change. [00:39:28] Yeah. So this is really important when you're building a...

00:39:32 - Anthony Campolo

Your root package.json, because this is the one in Ragged right now. And so this then uses Ragged as a dependency. And that's where the workspace is bringing it into the root level.

00:39:47 - Monarch Wadia

Correct.

00:39:48 - Anthony Campolo

Okay, great.

00:39:49 - Monarch Wadia

I'm not even sure if I need this, to be honest. The root package.json is just there because...

00:39:56 - Anthony Campolo

And I can see that this is just like the npm init dash yes boilerplate. You got an empty description, keyword, author. And the license is ISC.

00:40:06 - Monarch Wadia

Yeah, exactly. Let's fill those.

00:40:08 - Anthony Campolo

In right now.

00:40:09 - Monarch Wadia

Give yourself a description. Yeah, I probably should.

00:40:13 - Monarch Wadia

It's MIT licensed, really. So the license is here.

00:40:18 - Anthony Campolo

Change that, then.

00:40:19 - Monarch Wadia

I probably should.

00:40:20 - Monarch Wadia

I wonder what shows up on GitHub. So if I go to GitHub and I see Ragged, then... oh, yeah. The license doesn't show up over here. So you're right. I need to change that so that people can see that it's MIT licensed. Yeah, I'll have to get around to it.

00:40:41 - Anthony Campolo

Was there anything else in the Ragged package.json that you still wanted to explain?

00:40:49 - Anthony Campolo

Like, the scripts is just doing a build script, which is running a test suite. Are there actual tests?

00:40:56 - Monarch Wadia

Yep.

00:40:57 - Anthony Campolo

Where are the tests? Look at those. Exciting.

00:41:00 - Monarch Wadia

Yeah.

00:41:01 - Monarch Wadia

The driver is tested somewhat, so it's got tests that are actually...

00:41:07 - Anthony Campolo

A declaration only.

00:41:10 - Monarch Wadia

So what this does is it doesn't output code, it only outputs the types.

00:41:19 - Monarch Wadia

And that's important because if you go into build and if I go and... oh right, I have a VS Code ignore. Just a sec. So if I go into build and if I look at ragged.js, this is ragged.js. It's like this big monster.

00:41:41 - Monarch Wadia

Yeah.

00:41:41 - Monarch Wadia

But then if I go into main, then these are the type definitions. And if you look in source, then everything you see there is just .d.ts files. And these are all just type declarations that are automatically generated. And that's what emit, that's what that flag does inside.

00:42:01 - Monarch Wadia

Gotcha. Yeah.

00:42:03 - Anthony Campolo

Yeah, I don't use TypeScript a whole lot. So the TSC stuff, TS Node stuff, are things that I've used just very sparingly. One thing I did want to ask though, could we go into the Ragged src folder?

00:42:16 - Monarch Wadia

Yeah.

00:42:17 - Anthony Campolo

And then just go to like ragged.ts, or whatever the kind of root is.

00:42:22 - Monarch Wadia

Root file, sure, is a good one. Yeah. The root file is main.

00:42:29 - Monarch Wadia

So this is the main.

00:42:30 - Monarch Wadia

Okay.

00:42:31 - Anthony Campolo

And Ragged is implemented as a class.

00:42:34 - Monarch Wadia

Right. Yes.

00:42:36 - Monarch Wadia

And then there's also T which is the tool builder.

00:42:40 - Monarch Wadia

So we...

00:42:41 - Anthony Campolo

Talked about that a lot last time. So that makes sense. You're talking about importing T.

00:42:46 - Monarch Wadia

Yes.

00:42:47 - Anthony Campolo

Cool.

00:42:51 - Monarch Wadia

What do you want to do? Do you want to start building that thing on your end?

00:42:55 - Anthony Campolo

Well, there's a couple other questions I had. So, yeah, in terms of Node CLI stuff, Ragged is not a CLI. It's like a library that you actually write your JavaScript code with. So it's a little bit different from what I'm going to be building out.

And I mentioned Yargs to you. Are you familiar with that at all? And have you ever built out a CLI tool with Node before, I guess is my question.

00:43:23 - Monarch Wadia

Generally I've...

00:43:24 - Monarch Wadia

Used Yargs, I prefer Commander, but...

00:43:27 - Anthony Campolo

Let's take a look at that then. Tell me about Commander. Tell me why you prefer it. Because I did look at that and Yargs briefly and wasn't quite sure what I was supposed to pick. So this is going to be super useful for me to pick one and really go all in on it.

00:43:41 - Monarch Wadia

Okay.

00:43:42 - Monarch Wadia

Well, I like Commander because it's the first one that I picked up, and it was really easy to understand what it was doing. So Yargs is, I think, a little lower level and much more powerful, but I don't really need all that power. So I just use Commander because it's just easier and I'm more familiar with it.

So here's a typical program with Commander. This would be the main file. Program, that would be... this is what actually parses the input.

00:44:13 - Anthony Campolo

Can you bump up your font first?

00:44:15 - Monarch Wadia

Ah.

00:44:16 - Anthony Campolo

And then just say the last part again. Sorry.

00:44:18 - Monarch Wadia

Sure.

00:44:19 - Monarch Wadia

So here's a typical Commander program from their docs. Program.parse, just starting at the bottom here. Program.parse is where it parses the arguments that were passed into the Node script.

So you can imagine if you do something like ls -a, then -a is part of the context of your CLI program, right? So program.parse does all the hard work of parsing the actual command line arguments.

And then you have the actual program. The program itself has a name, a description, a version. And then it has commands.

So over here this thing would be, you'd be able to do string-util split and then pass an argument. And you can pass in a couple of options. So one is "first," so just display the first substring. The second is -s, so you can specify a custom separator character. But what you're doing is string-util split and then the string itself.

[00:45:25] And here's the handler that will handle the CLI command. And all the parsing of the CLI command is done by program. So you don't have to worry about the low level stuff.

00:45:37 - Anthony Campolo

Okay. Yeah. No, that was super useful. Fuzzy Bear was talking about how he has a course, apparently, about Commander. I told him to drop a link, and I'll share that, or I'll go find it later and put it in.

So let me show you what I got to with Yargs. Let me go to share screen. So this was kind of... and I never used it before, so I kind of built this with ChatGPT just like writing a bunch of code for me. And it probably ended up being totally ridiculous.

So I've got this giant file. It's doing a whole bunch of stuff, so I need to remind myself what is even happening here. So let me pull this up next to the one that I ended up having finished.

[00:46:29] So this is where we had the bash script that was showing last time, and then this is what I was trying to implement, all just in Node. So you had the yt-dlp command here and here. So this is where it's extracting the audio. And then the Whisper command is happening down here.

And I have abstracted it as kind of one off commands that then were all being run as encapsulated functions that were being called, I think at the... yes. Here is where they all get called. So you fetch the metadata, extract the info, download audio, transcribe audio, transform to markdown, and then generate markdown from metadata.

So I ended up with this huge nested structure of functions that are doing each of the things. And here's the actual Yargs stuff. It's just the option is an alias where you can feed it the URL and then type string. So this is what you were just showing in terms of Commander does kind of this part.

[00:47:48] And I think that's going to make a lot more sense if I start thinking of that first, like what's the functionality, what are the flags. Because I did end up getting it to where I have three things that I know are going to be the baseline functionality that I want this to do.

Just to start with, I want to be able to give it a playlist, and then it will run on all the videos in the playlist. I want to give it just a single video, and it'll just run a single video. And then I want to be able to give it just a list of URLs. So if someone just wanted to go grab a couple of YouTube videos, put them into a file, just list them all out and then run that arbitrarily, they can do that.

So these would be the first three things that I would want to do. And it seems like what you're showing me with Commander is going to be great for that, because I can just have flags that do each of these kind of things.

00:48:38 - Monarch Wadia

Yeah, exactly. And once you install it with npm, it exposes this thing called the scripts... a scripts declaration. So if you look at the scripts declaration, you can... yeah, that's where you put in. You can put in one, you can put in two, you can put in three. But this is where you can put in all of the scripts. Oh sorry. My bad. Not scripts, bin. My bad.

00:49:09 - Anthony Campolo

Yeah. That was like, this is just like scripts but yeah. And npm, I know of this, this is the bin command. This is not what I want. This is why I hate npm documentation. I want npm package.json bin, is what I actually want. And so we want this. We want to go here. This is what we want, right? [00:49:30] - Monarch Wadia That's exactly it.

00:49:31 - Monarch Wadia

Yeah. Yes.

00:49:34 - Anthony Campolo

Exactly what I want on the npm docs.

00:49:36 - Monarch Wadia

Me too. This is where...

00:49:38 - Anthony Campolo

The bin is just arbitrary scripts. That's why even here they're talking about if you have a CLI.

00:49:46 - Monarch Wadia

Exactly.

00:49:46 - Monarch Wadia

And then my app will become a...

00:49:48 - Monarch Wadia

Global, so you'll be able to just run my app from your CLI. And that's how Prisma does this thing. I'm guessing it'll just install the binary using npm and you get it available globally everywhere.

00:50:05 - Anthony Campolo

Okay, cool. Great. So we're getting close to the hour mark here. This is going to require me doing a lot of hacking and a lot of back and forth and stuff breaking and me kind of figuring it out. This could be a good learning exercise for me.

So instead of having you painfully walk me through that whole process, I may do that on my own. And then next time we meet up, I can show you how far I got. You can help me out. I think that'll be probably the thing to do.

Were there other things you wanted to talk about in terms of just Ragged or this whole process, or learnings you've had along the way from doing all this?

00:50:46 - Monarch Wadia

I think the easier thing to do would be, sorry, not easier. But yeah, I agree with you. I think if I was to give you a heads up and give you a tip to make your work a little easier...

00:51:03 - Monarch Wadia

Mhm.

00:51:03 - Monarch Wadia

If I were you, I would publish something fast and then incrementally publish versions. So your 0.0.1 might be just an empty thing that does nothing. And then 0.0.2 might be a Hello World, and going from nothing to Hello World is going to be kind of painful in itself because you'll figure out issues.

00:51:30 - Monarch Wadia

Well, probably.

00:51:31 - Anthony Campolo

What I'm going to do if you're okay with this is I'm just going to fork your repo and just delete all the Ragged stuff just so I have the baseline setup and then see where that gets me.

00:51:44 - Monarch Wadia

I wouldn't recommend it, but you can do it.

00:51:46 - Monarch Wadia

I wouldn't...

00:51:47 - Anthony Campolo

Recommend it. Okay. Why?

00:51:49 - Monarch Wadia

Because it's actually going to be harder to remove stuff than it is to add stuff, because it's actually dead simple to create npm packages. So if I were you, I would just make a little package and we could do it probably in ten minutes.

00:52:09 - Anthony Campolo

Yeah. Let's do it.

00:52:10 - Monarch Wadia

Yeah.

00:52:12 - Anthony Campolo

So let me share my screen again.

00:52:14 - Monarch Wadia

Cool.

00:52:16 - Anthony Campolo

Okay. So should I start with the repo I already have, or should I start with a blank repo?

00:52:24 - Monarch Wadia

Let's start with a new one. So let's start with a brand new repo.

00:52:28 - Monarch Wadia

Okay.

00:52:33 - Anthony Campolo

I'm just gonna call it auto gen npm. Okay, so do I start by initializing the npm package?

00:52:51 - Monarch Wadia

Yep, yep.

00:52:57 - Monarch Wadia

And you might want to give it a name. I think auto gen might be taken.

00:53:04 - Anthony Campolo

Let me just do auto gen AJC. How about that?

00:53:06 - Monarch Wadia

Cool.

00:53:07 - Monarch Wadia

That's probably not taken. So for version, do you care or do you want to make it like...

00:53:14 - Monarch Wadia

Start with that. Okay. Sweet.

00:53:20 - Monarch Wadia

Yeah, that's perfect. And you might want to add a readme.

00:53:25 - Monarch Wadia

Yeah. Some sort of...

00:53:27 - Anthony Campolo

Do I need a git ignore?

00:53:32 - Monarch Wadia

Do I need a git ignore? Probably not for this initial thing.

00:53:36 - Anthony Campolo

Not even a .DS_Store? I guess you're not on a Mac, so that's not a thing for you.

00:53:42 - Monarch Wadia

The magic here is that this has nothing to do with git. You can manage it however you want. If you want to do a git init and do all that, we can do that.

00:53:51 - Monarch Wadia

So let's do it.

00:53:53 - Monarch Wadia

Okay.

00:53:54 - Anthony Campolo

Let me just do this first then. And let me actually do this here because I got Warp. So I'm gonna do GCP and then...

00:54:15 - Monarch Wadia

Okay.

00:54:20 - Anthony Campolo

That's not that one.

00:54:29 - Monarch Wadia

Sorry.

00:54:30 - Anthony Campolo

I have a massive command that usually comes up.

00:54:33 - Monarch Wadia

Let me just grab this real quick for sake of simplicity. This one.

00:55:03 - Monarch Wadia

Okay.

00:55:04 - Monarch Wadia

That's good.

00:55:05 - Monarch Wadia

Cool.

00:55:05 - Monarch Wadia

What terminal is this? It's nice.

00:55:07 - Anthony Campolo

Yeah. It's Warp, so it's like a VC funded company. Yeah, it's just nice. It gives you functionality. You can click around and it just makes it easier to work with stuff in general.

Usually if I just did that, that would come up. That's why I was kind of thrown off because I'm like, where's my giant command?

00:55:28 - Monarch Wadia

Gotcha. Okay, so you have your GitHub set up, package.json. I think you might have to give it a main.js even if it's empty.

00:55:37 - Monarch Wadia

Okay.

00:55:38 - Monarch Wadia

Or index.js.

00:55:41 - Anthony Campolo

And you want me to just console.log something?

00:55:43 - Monarch Wadia

Hello World or something.

00:55:43 - Monarch Wadia

Sure. Yeah.

00:55:48 - Anthony Campolo

Okay.

00:55:49 - Monarch Wadia

Yeah.

00:55:51 - Monarch Wadia

And then if you want to commit that, you can commit that.

00:55:53 - Monarch Wadia

Yeah.

00:55:54 - Monarch Wadia

And now you can do an npm publish. [00:55:58] - Monarch Wadia Okay.

00:55:59 - Anthony Campolo

So am I gonna have to...

00:56:02 - Monarch Wadia

So you need to log in. You can follow registry dot... let's see. You need to authorize, right? So type npm adduser like it says over there. All one word.

00:56:15 - Monarch Wadia

Yeah.

00:56:16 - Monarch Wadia

So go...

00:56:17 - Monarch Wadia

Over there.

00:56:18 - Anthony Campolo

Let me just do this off screen just for a second, cause I don't know what's about to happen right now.

00:56:25 - Monarch Wadia

Oh.

00:56:28 - Anthony Campolo

Geez, do I even have an npm account?

00:56:33 - Monarch Wadia

It's easy to start one. Yeah.

00:56:36 - Anthony Campolo

This shouldn't take me very long.

00:56:39 - Monarch Wadia

I think you might have to enable 2FA to be able to publish.

00:56:43 - Anthony Campolo

Yeah, I'm pretty sure that's the case.

So how to do a puzzle to verify that I'm a human? That train is pointing right. So silly.

Okay. Create account and then set one time password to my email, which I definitely don't want to be shown on screen.

00:57:15 - Monarch Wadia

Okay.

00:57:16 - Anthony Campolo

Just real quick while I'm doing this, do you understand this comment?

00:57:21 - Monarch Wadia

Oh.

00:57:24 - Monarch Wadia

Yeah. You have to make it executable and change the owner so that the file is owned by the current owner.

I'm not sure. It might be something that you have to do. Maybe not, because it's a Node.js file. So I wonder if you actually have to chmod the script. Maybe, maybe not. It's permission stuff. Linux permission stuff.

00:57:50 - Monarch Wadia

Makes sense.

00:57:53 - Anthony Campolo

Okay, I'm just cleaning up my screen real fast, closing all my tabs and stuff, and definitely close my 1Password.

00:58:03 - Monarch Wadia

Okay. Oops.

00:58:13 - Anthony Campolo

Now I gotta do another one time password at the CLI. Yeah, this is probably going to be the most complicated part.

Okay, so let me share my stuff again. Did it work? I think...

00:58:40 - Monarch Wadia

It did. Check it out.

00:58:42 - Monarch Wadia

I think it did.

00:58:43 - Short interjection

Whoa! Oh, baby.

00:58:47 - Monarch Wadia

I think you just go to npm and then look for autogen-ajc.

00:58:53 - Anthony Campolo

Hey, look at that.

00:58:55 - Monarch Wadia

There you go. Hey.

00:58:56 - Anthony Campolo

Man, you're right. That was easy. Sweet.

00:58:58 - Monarch Wadia

Yeah.

00:59:00 - Monarch Wadia

Now, the difficult part is, okay, I'm going to try and install it on my local and I'm going to see if it actually works.

00:59:06 - Monarch Wadia

Cool. Good stuff.

00:59:07 - Anthony Campolo

Do you want to share? If something happens, yeah, feel free to.

00:59:14 - Monarch Wadia

Yeah, let me share.

00:59:25 - Anthony Campolo

I'll add that to the stage.

00:59:27 - Monarch Wadia

I want to do npm add autogen-ajc. Hope there's no malware on there. And that added just fine.

00:59:35 - Monarch Wadia

There you go. And yeah, look at that.

00:59:39 - Monarch Wadia

You got your first user.

00:59:40 - Monarch Wadia

So that added just fine.

00:59:43 - Monarch Wadia

And then I'm going to just import autogen-ajc. There you go. Your code is running on my machine.

00:59:55 - Anthony Campolo

Hell yeah, that's tight. That was a really great Hello World exercise actually, that was sweet. Great, thanks for doing that with me.

01:00:03 - Monarch Wadia

Yeah, for sure. I guess the next question is, well, how do you create scripts? And if you wanted to export something, how do you do that?

So you just have to, for the bin, you can just do something like this and call it, I don't know, I'm just going to call it AJC. And you would do something like that inside your package.json. And then you can go inside index.js and then start building your code.

And I think that should actually be enough. That should actually work. And if you do that right now, I can be your first tester, and then if we do it in the next ten minutes, I think we can say we published an npm package.

01:00:53 - Anthony Campolo

Great.

01:00:56 - Monarch Wadia

Or we can do it next time. I'll see you.

01:00:58 - Anthony Campolo

Yeah, so my mind is already going to the actual autogen stuff, because what I'm thinking is there's kind of two directions that need to go with this. I need to be able to execute the npm scripts, which is what you just said. And then I also need to get my thing into a form where either I'm going to call the bash script from npm, or try to do what I did the first time where I actually build it out.

So basically, I just kind of got a million directions right now, so I kind of froze up there. I think we should call it here. I think I want to think about where I want to take this from here because it's just like me going through this, taking notes and writing stuff as I'm doing it and possibly turning this into a blog post as well.

01:01:48 - Anthony Campolo

But where you got me is super useful and I really appreciate it. I think this is probably a good place for us to stop.

01:01:56 - Monarch Wadia

I can sense the excitement. Awesome. Let me know if you need any help. I'm always here, if you get stuck or anything.

I think the main stuff that I'm sort of worried about is, well, you have a lot of stuff in C++, so how are you going to do that in Node? You can call C++ from Node, but the problem with C++ is you'll have to compile it before you actually push it. And you'll have to compile it for all sorts of different architectures. So it might be easier when possible to actually convert the code into Node and have as little C++ as possible. But yeah, I think you got this, man.

01:02:32 - Anthony Campolo

Yeah. And there's things with Whisper that can kind of reach out to Node. They have a Node add-on. So I need to look into that as well and see whether it's going to make sense to use that or just try and wrap it myself like you were describing. That's going to be interesting.

But yeah, this is such a good project for me to do because I've already learned a bunch having done it. And it's actually forcing me to interface with a lot of stuff that I haven't before, just being a lowly front-end developer slinging React components.

01:03:09 - Short interjection

Nah.

01:03:10 - Monarch Wadia

Nah, man. This is going to be so much fun. Let me know if I can do anything.

01:03:14 - Anthony Campolo

Well, I was thinking, are you cool kind of continuing to do these, maybe once a week or something? And then we can also work on Ragged stuff at the same time. I want to make this as worthwhile for you as possible and not just have you build out my stuff.

But I really am enjoying the ride, and I think there's a way we can combine the two in a sense, because there's no library in what I'm doing right now that does the LLM part, like I'm reaching out to. So these two things I think can arrive in a similar direction in one sense. I would really like to keep doing these every week with you.

01:03:49 - Monarch Wadia

I'd love that. Yeah, I can see a few ways to do it. Maybe we can have a natural language interface instead of a CLI interface or something similar, I don't know. But yeah, for sure.

01:04:00 - Anthony Campolo

Yeah, man. That's exciting. Great, so for people who want to keep following along, this is AJC Web Devs on the internet everywhere. You can find me on YouTube at just AJ Web Dev. And then Monarch, you are at Monarch Wadia on Twitter, just straight up name. So we got that as well for people who want to check out your stuff. And if someone wants to hire you, you're hirable.

01:04:40 - Monarch Wadia

Yes. And maybe I should drop my LinkedIn because that seems to be the thing to do. Oh, that's connected. Do you want to drop it?

01:04:51 - Anthony Campolo

I got it. Yeah, it was the first thing to come up.

01:04:56 - Short interjection

Thank you.

01:04:59 - Monarch Wadia

Fuzzy TV just said, "I love the stream." Yeah.

01:05:03 - Short interjection

Feeling's mutual.

01:05:04 - Anthony Campolo

Yeah, Fuzzy is a good buddy. He's been following a lot of my content for a while.

01:05:11 - Monarch Wadia

So he just said, "FYI, I bleep and hate Python."

01:05:18 - Anthony Campolo

That's your LinkedIn, right?

01:05:20 - Short interjection

Yeah. Thank you.

01:05:22 - Anthony Campolo

Yeah, we are doing all of this without Python. We are bucking the AI trend. We're doing all JavaScript front to back. Nothing but JavaScript tooling.

01:05:32 - Short interjection

I think that's the future.

01:05:33 - Monarch Wadia

Honestly, Python is great, but I have opinions.

01:05:36 - Short interjection

Okay.

01:05:39 - Monarch Wadia

I'm less employable. I should stop dissing Python.

01:05:43 - Short interjection

That's funny.

01:05:44 - Anthony Campolo

All right, so we'll catch you guys, I think same time next week, if that's good with you.

01:05:49 - Short interjection

Yep, absolutely. That works.

01:05:52 - Anthony Campolo

All right.

01:05:52 - Short interjection

Bye everyone. Thank you, Anthony.

01:05:54 - Anthony Campolo

Yeah, thank you.

01:05:56 - Short interjection

Bye bye.