JSJ 266 NPM 5.0 with Rebecca Turner

JSJ 266 NPM 5.0 with Rebecca Turner

On today’s episode of JavaScript Jabber, Charles Max Wood and panelist Joe Eames chat with Rebecca Turner, tech lead for https://www.npmjs.com/, a popular Javascript package manager with the worlds largest software registry. Learn about the newly released NPM 5 including a few of the updated features. Stay tuned![1:58] Was the release of node JS 8 tied to NPM5?
- Features in NPM5 have been in planning for 2 years now.
- Planned on getting it out earlier this year.
- Node 8 was coming out and got pushed out a month.
- Putting NPM5 into Node 8 became doable.
- Pushed really hard to get NPM5 into https://nodejs.org/en/blog/release/v8.0.0/ so that users would get NPM5 and updates to NPM5.
[2:58] Why would it matter? NPM doesn’t care right?
- Right you can use NPM5 with any version of node.
- Most people don’t update NPM, but upgrade Node.
- So releasing them together allowed for when people updated Node they would get NPM 5.
[3:29] How does the upgrade process work if you’re using NVM or some node version manager?
- Depends. Different approaches for each
- NVM gets a fresh copy of Node with new globals. NVM5 and Node 8 are bundled.
- For some, If you manually upgrade NVM you’ll always have to manually. It will keep the one you manually upgraded to.
[4:16] Why NPM 5?
- It’s night and day faster.
- 3 to 5 times speed up is not uncommon.
- Most package managers are slow.
- NPM 5 is still growing. Will get even faster.
[5:18] How did you make it faster?
- The NPM’s cache is old. It’s very slow. Appalling slow.
- Rewrote cache
- Saw huge performance gains
[5:49] What is the function of the cache?
- Cache makes it so you don’t have to reinstall modules from the internet.
- It has registry information too.
- It will now obey http headers for timing out cache.
[6:50] Other things that made it faster?
- Had a log file for a long time. It was called https://docs.npmjs.com/cli/shrinkwrap.
- NPM 5 makes it default.
- Renamed it to packagelog.json
- Exactly like shrinkwrap package file seen before
- In combo with cache, it makes it really fast.
- Stores information about what the tree should look like and it’s general structure.
- It doesn’t have to go back and learn versions of packages.
[7:50] Can you turn the default Packagelog.json off?
- Yes. Just:
- Set packagelog=false in the npmrc
[8:01] Why make it default? Why wasn’t it default before?
- It Didn’t have it before. Shrinkwrap was added as a separate project enfolded in NPM and wasn’t core to the design of NPM.
- Most people would now benefit from it. Not many scenarios where you wouldn’t want one.
- Teams not using the same tools causes headaches and issues.
[9:38] Where does not having a lock show up as a problem?
- It records the versions of the packages installed and where NPM put them so that when you clone a project down you will have exactly the same versions across machines.
- Collaborators have the exact same version.
- Protects from issues after people introduce changes and patch releases.
- NPM being faster is just a bonus.
- Store the sha512 of the package that was installed in the glock file so that we can verify it when you install. It’s Bit for bit what you had previously.
[11:12] Could you solve that by setting the package version as the same version as the .Json file?
- No. That will lock down the versions of the modules that you install personally, not the dependancies, or transitive dependancies.
- Package log allows you to look into the head of the installer. This is what the install looks like.
[12:16] Defaulting the log file speed things up? How?
- It doesn’t have to figure out dependences or the tree which makes it faster.
- Shrinkwrap command is still there, it renames it to shrinkwrap but shrinkwrap cannot be published.
- For application level things or big libraries, using shrinkwrap to lock down versions is popular.
[13:42] You’ve Adopted specifications in a ROC process. When did you guys do that?
- Did it in January
- Have been using them internally for years. Inviting people into the process.
- Specifications
- Written in the form of “Here is the problem and here are the solutions.”
- Spec folder in NPM docs, things being added to that as they specify how things work.
- Spec tests have been great.
[14:59] The update adds new tools. Will there be new things in registry as well?
- Yes.
- Information about a package from registry, it returns document that has info about every version and package json data and full readme for every version.
- It gets very large.
- New API to request smaller version of that document.
- Reduces bandwidth, lower download size, makes it substantially faster.
- Used to be hashed with sha1, With this update it will be hashed with sha512 as well as sha1 for older clients.
[16:20] Will you be stopping support for older versions?
- LTS version of NPM was a thing for a while. They stopped doing that.
- Two models, people either use whatever version came with Node or they update to the latest.
- The NPM team is really small. Hard to maintain old NPM branches.
- Supports current versions and that’s pretty much it.
- If there are big problems they will fix old versions. Patches , etc.
[17:36] Will there ever be problems with that?
- Older versions should continue to work. Shouldn’t break any of that.
- Can’t upgrade from 0.8.
- It does break with different Node version
- Does not support Node versions 0.10 or 0.12.
[18:47] How do you upgrade to NPM?
- sudo npm install -gmpm
- Yes, you may not need sudo. depend on what you’re on.
[19:07] How long has it been since version 4?
- Last October is when it came out.
[19:24] Do you already have plans for version 6?
- Yes!
- More releases than before coming up.
- Finally deprecating old features that are only used in a few packages out of the whole registry.
- Running tests on getting rid of things.
[20:50] Self healing cache. What is it and why do we want it?
- Users are sometimes showing up where installs are broken and tarbols are corrupted.
- This happens sometimes with complicated containerization setups makes it more likely. It’s unclear where the problem actually is.
- https://www.npmjs.com/package/cacache - content addressable cache. Take the hash of your package and use it to look up address to look it up in the cache.
- Compares the Tarbol using an address to look it up in the cache.
- Compares to see if it’s old. Trashes old and downloads updated one.
- Came out with the cache. Free side effect of the new cache.
[23:14] New information output as part of the update?
- NPM has always gave back you the tree from what you just installed.
- Now, trees can be larger and displaying that much information is not useful.
- User patch - gives you specifically what you asked for.
- Information it shows will be something like: “I installed 50 items, updated 7, deleted 2.”
[24:23] Did you personally put that together?
- Yes, threw it together and then got feedback from users and went with it.
- Often unplanned features will get made and will be thrown out to get feedback.
- Another new things ls output now shows you modules that were deduped. Shows logical tree and it’s relationships and what was deduped.
[25:27] You came up to node 4 syntax. Why not go to node 8?
- To allow people with just node 4 be able to use NPM.
- Many projects still run Node 4. Once a project has been deployed, people generally don’t touch it.
[26:20] Other new features? What about the File Specifier?
- File specifier is new. File paths can be in package json, usually put inside pointing to something inside your package.
- It will copy from there to your node modules.
- Just a node module symlink.
- Much faster. Verifiable that what’s in your node modules matches the source. If it’s pointing at the right place it’s correct. If not, then it’s not.
- Earlier, sometimes it was hard to tell.
[27:38] Anything else as part of the NPM 5 release? Who do you think will be most affected by it?
- For the most part, people notice three things:
- 1st. no giant tree at the end
- 2nd. Much faster
- 3rd. Package lock.
[28:14] If it’s locked, how do you update it?
- Run npm installer and then npm update
- Used to be scary, but works well now.
- Updates to latest semver, matches semver to package json to all node modules.
- Updates package lock at the same time
- Summary in Git shows what’s changed.
[28:59] Did Yarn come into play with your decisions with this release?
- The plans have been in play for a long time for this update.
- https://yarnpkg.com/en/ inclusion of similar features and the feedback was an indicator that some of the features were valuable.
[29:53] Other plans to incorporate features similar to yarn?
- Features are already pretty close.
- There are other alternative package managers out there.
- PMPM interesting because when it installs it doesn’t copy all the files. It c

Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

Episoder(734)

The Comeback of RPC: SolidJS, TanStack, and the Future of JavaScript Frameworks with Ryan Carniato & Tanner Linsley - JSJ 691

The Comeback of RPC: SolidJS, TanStack, and the Future of JavaScript Frameworks with Ryan Carniato & Tanner Linsley - JSJ 691

In this episode of JavaScript Jabber, I sit down with Ryan Carniato, creator of SolidJS, and Tanner Linsley, the force behind TanStack, for a deep-dive conversation on the resurgence of Remote Procedure Calls (RPC) in modern web development. We explore why RPC is making a comeback, how frameworks like Solid, TanStack, and others are shaping the way we think about data fetching, and the technical innovations that are driving this movement forward.From streaming and serialization to type safety and the future of client-server communication, Ryan and Tanner share their experiences, insights, and the unique challenges they’ve faced building cutting-edge tools for developers. If you’ve been curious about where RPC fits in today’s frameworks—or just love geeking out about performance, signals, and developer experience—this is one episode you won’t want to miss.Links & ResourcesRyan Carniato on SolidJSTanStack (React Query, Router, Table, and more)Sentry – where Ryan is currently workingCreate TanStackSolidJS DiscordRyan CarniatoRyan Carniato is the creator of SolidJS, a high-performance JavaScript framework built on fine-grained reactivity. He’s also a Senior Software Engineer at Sentry, where he explores new approaches to front-end architecture and developer experience. Through his open-source contributions, talks, and in-depth content, Ryan has become a trusted voice in the web development community, helping developers think differently about building fast, reactive applications.Tanner LinsleyTanner Linsley is the founder of TanStack, the home of widely adopted open-source libraries like TanStack Query (formerly React Query), TanStack Router, Table, Virtual, and more. A full-time open-source entrepreneur, Tanner has redefined how developers manage state, caching, and data fetching in modern applications. With a focus on performance, simplicity, and type safety, his tools power some of the most advanced applications on the web today.Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

22 Sep 1h 29min

Exploring Vibe Coding and the Future of Product Management with Gunnar Berger - JSJ 690

Exploring Vibe Coding and the Future of Product Management with Gunnar Berger - JSJ 690

In this episode of JavaScript Jabber, I sit down with Amazon product leader Gunnar Berger to dive into the fast-evolving world of vibe coding and how it’s reshaping the relationship between developers and product managers. Gunnar brings a wealth of experience from his years in IT, Citrix, and now Amazon, and shares a unique perspective on how AI tools are changing the way products get built—from idea to prototype.We talk about the shifting role of product managers, how AI is compressing traditional workflows, and what it means for developers, UX designers, and even junior devs entering the industry. From rapid prototyping to AI-assisted documentation, Gunnar opens up about both the opportunities and the challenges this new paradigm introduces. Whether you’re a developer, product manager, or just curious about where AI is taking us, this conversation is packed with insights you won’t want to miss.Links & ResourcesGunnar Berger on LinkedInCloud CodeCursorKiro.devIf you enjoyed this episode, don’t forget to rate, review, and follow JavaScript Jabber on your favorite podcast app. And of course—share it with a friend who’d love to learn more about the future of coding and product management!Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

12 Sep 1h 13min

How to Use Web Components, Iframes, and Module Federation for Multi-Framework Apps - JSJ 689

How to Use Web Components, Iframes, and Module Federation for Multi-Framework Apps - JSJ 689

This week on JavaScript Jabber, we dive deep into the challenges and opportunities of mixing and matching frontend frameworks in modern applications. I’m joined by Dan Shapir, Steve Edwards, and our special guest Hadar Geva, CTO and co-founder of Myop.dev. Together, we explore how companies are tackling multi-framework environments, the role of web components and iframes, and why module federation isn’t always as simple as it sounds.We also take a closer look at how AI is changing the way developers and even non-developers generate code, the risks of integrating AI-written components, and strategies for safely managing that code in production. If you’ve ever struggled with legacy frameworks, integrating AI-generated components, or wondered whether web components or local iframes are the better fit—this episode is packed with insights you won’t want to miss.Links & ResourcesMyop.dev – Hadar’s company, building solutions for mixing and managing micro-frontends.Web Awesome – Web components library mentioned during picks.AG Grid – Heavy-duty data grid solution.TanStack Table – Lightweight table solution by Tanner Linsley.ShadCN UI – Component library for modern React apps.Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

2 Sep 1h 17min

Why We’re Building the Front End Wrong (and How to Fix It) - JSJ 688

Why We’re Building the Front End Wrong (and How to Fix It) - JSJ 688

In this episode of JavaScript Jabber, I sit down with Delaney Gilliland to dive into why most of us are building the front end wrong—and what a faster, leaner, and simpler alternative could look like. We explore his background in game development and military applications, which gave him a unique perspective on web performance and real-time data challenges. That perspective ultimately led him to create Datastar, a new framework designed to rethink the way we approach front-end development.We talk about the limitations of SPAs, the promise (and pitfalls) of tools like HTMX and Turbo, and how Datastar builds on web standards to deliver speed, efficiency, and simplicity without the baggage of heavy state management. Whether you’re curious about server-sent events, morphing strategies, or just want to see how front-end development could be done differently, this conversation will get you thinking about the future of the web.Links & ResourcesDatastar official sitehttps://x.com/DelaneyGillilanhttps://github.com/delaneyjBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

28 Aug 46min

Vibe Coding: Building Faster with AI-Powered Development - JSJ 687

Vibe Coding: Building Faster with AI-Powered Development - JSJ 687

In this episode of JavaScript Jabber, we dive deep into the world of vibe coding—what it means, how it works in practice, and why it’s changing the way developers build software. I’m joined by Anthony Campolo, who shares his hands-on experience developing AutoShow, an app that automates podcast show notes, using AI-assisted workflows. We talk about how tools like Claude, ChatGPT, and Gemini accelerate development, the role of rule files, and the balance between automation and manual QA.Along the way, we explore the impact of LLMs on junior vs. senior developers, how companies are adapting AI-driven coding practices, and whether the future of software development still requires humans in the loop. This conversation blends real-world coding insights, practical tools, and some big-picture questions about where AI is taking the industry.Check out Anthony Campolo here.Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

22 Aug 1h 11min

The Next Wave of Dev Tools: AI Assistants and JavaScript Workflows - JSJ 686

The Next Wave of Dev Tools: AI Assistants and JavaScript Workflows - JSJ 686

In this episode of JavaScript Jabber, we sit down with Vinicius Dallacqua, a seasoned software engineer with a passion for performance and developer tooling. Vinicius shares his journey from coding in central Brazil with limited connectivity to building cutting-edge tools like PerfLab and PerfAgent. We dive into the intersection of AI and DevTools, exploring how artificial intelligence is transforming performance debugging, web development workflows, and even the future of browsers.We also tackle the big questions: How do developers avoid bias when building in high-performance environments? What role will agentic browsers play in the evolution of the web? And how can AI-powered DevTools lower the barrier for developers intimidated by performance profiling? If you’re curious about the future of frontend performance, DevTools, and AI-driven development, this conversation is packed with insights.Links & ResourcesPerfLab – Performance tooling platformPerfAgent – AI-powered DevTools assistantVinicius Dallacqua on X (Twitter)Paul Kinlan’s AI Focus – Essays on AI and the webPerfNow Conference – Leading performance conference in AmsterdamBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

14 Aug 1h 6min

Inside VueConf: Nuxt 4, AI in Development, and the Future of Vue with Erik Hanchett - JSJ 685

Inside VueConf: Nuxt 4, AI in Development, and the Future of Vue with Erik Hanchett - JSJ 685

In this episode of JavaScript Jabber, we welcome back Erik Hanchett, Senior Developer Advocate at AWS, to dive into his experience at VueConf. From the energy of the Vue community to lightning talks on AI and Nuxt updates, Erik shares his insights on where Vue is heading and why in-person conferences are still so valuable for developers. We also explore the balance between “vibe coding” and spec-driven development, plus Erik introduces us to Amazon Q CLI and its powerful MCP integrations for smarter AI-assisted coding.Along the way, we discuss the evolving state of Vue, the rise of Nuxt 4, Evan You’s projects (including Vite and RollDown), and how Amplify is simplifying full-stack app development on AWS. Whether you’re a Vue developer, curious about AI in frontend workflows, or just want to catch up on what’s happening in the broader JavaScript ecosystem, this episode is packed with insights you won’t want to miss.🔗 Links & ResourcesAmazon Q Developer CLI on GitHubAWS Amplify DocumentationCommit Your Code ConferenceErik Hanchett on X (Twitter)Program With Erik YouTube ChannelBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

8 Aug 58min

Running Doom in TypeScript’s Type System with Dimitri Mitropoulos - JSJ 684

Running Doom in TypeScript’s Type System with Dimitri Mitropoulos - JSJ 684

What if I told you someone managed to run Doom inside TypeScript’s type system? Sounds insane, right? That’s exactly what our guest Dimitri Mitropoulos did—and in this episode, we dive deep into the how, the why, and the mind-bending implications of this ambitious project. From type-level programming to the philosophical limits of Turing completeness, this is an episode that pushes the boundaries of what you thought was possible in JavaScript.We talk about how the TypeScript type system evolved to become Turing-complete, how Dimitri pulled off this seemingly impossible feat, and why “Doom-complete” might just be the new gold standard for computational capability. Along the way, we touch on functional programming, generics, recursion, and even some Lambda Calculus. It’s part computer science theory, part coding madness, and 100% geeky goodness.Episode Highlights[3:05] – Dimitri explains how a simple thought experiment turned into a year-and-a-half-long obsession[8:40] – The origins and significance of Turing completeness in type systems[14:15] – Why running Doom in TypeScript is more about proving limits than just showing off[19:55] – What it means to run programs inside the type system vs. TypeScript code itself[27:10] – ASCII art as output, functional recursion for game state, and hover-over frames in your editor[35:30] – How ignorance, determination, and obsession fueled the completion of the project[45:20] – Personal insights: balancing family, burnout, and passion while chasing an impossible dreamLinks & ResourcesDimitri MitropoulosMichigan TypeScript YouTube Channel – Dimitri's channel featuring the projectType Challenges by Anthony Fu – Advanced TypeScript exercisesSquiggleConf – The TypeScript-focused conference Dimitri co-foundedJosh Goldberg – TypeScript expert and co-organizer of SquiggleConfBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

1 Aug 1h 18min

Populært innen Business og økonomi

stopp-verden
dine-penger-pengeradet
lydartikler-fra-aftenposten
rss-penger-polser-og-politikk
kommentarer-fra-aftenposten
e24-podden
rss-borsmorgen-okonominyhetene
utbytte
finansredaksjonen
pengepodden-2
tid-er-penger-en-podcast-med-peter-warren
pengesnakk
stormkast-med-valebrokk-stordalen
livet-pa-veien-med-jan-erik-larssen
morgenkaffen-med-finansavisen
rss-markedspuls-2
okonomiamatorene
rss-investering-gjort-enkelt
rss-fri-kontantstrom
paretopodden