Could not resolve “@popperjs/core”

I keep getting this error on running dev. Albeit it doesn’t appear I’m getting it in production.

I run.

npm run dev

Then everything appears to be ok, with the standard message like this from vite.

  vite v2.9.9 dev server running at:

  > Local: http://localhost:3000/
  > Network: use `--host` to expose

  ready in 740ms.

But then, once I navigate to the site to check things out.

X [ERROR] Could not resolve "@popperjs/core"

    node_modules/bootstrap/dist/js/bootstrap.esm.js:6:24:
      6 │ import * as Popper from '@popperjs/core';
        ╵                         ~~~~~~~~~~~~~~~~

  You can mark the path "@popperjs/core" as external to exclude it from the bundle, which will
  remove this error.

…and this error annoyingly crops up.

11:36:23 PM [vite] error while updating dependencies:
Error: Build failed with 1 error:
node_modules/bootstrap/dist/js/bootstrap.esm.js:6:24: ERROR: Could not resolve "@popperjs/core"
    at failureErrorWithLog (C:\Users\Adron Hall\Codez\estuary\node_modules\esbuild\lib\main.js:1603:15)
    at C:\Users\Adron Hall\Codez\estuary\node_modules\esbuild\lib\main.js:1249:28
    at runOnEndCallbacks (C:\Users\Adron Hall\Codez\estuary\node_modules\esbuild\lib\main.js:1034:63)
    at buildResponseToResult (C:\Users\Adron Hall\Codez\estuary\node_modules\esbuild\lib\main.js:1247:7)
    at C:\Users\Adron Hall\Codez\estuary\node_modules\esbuild\lib\main.js:1356:14
    at C:\Users\Adron Hall\Codez\estuary\node_modules\esbuild\lib\main.js:666:9
    at handleIncomingPacket (C:\Users\Adron Hall\Codez\estuary\node_modules\esbuild\lib\main.js:763:9)
    at Socket.readFromStdout (C:\Users\Adron Hall\Codez\estuary\node_modules\esbuild\lib\main.js:632:7)
    at Socket.emit (events.js:315:20)
    at addChunk (_stream_readable.js:309:12)
Vite Error, /node_modules/.vite/deps/pinia.js?v=72977742 optimized info should be defined
Vite Error, /node_modules/.vite/deps/bootstrap.js?v=14c3224a optimized info should be defined
Vite Error, /node_modules/.vite/deps/pinia.js?v=72977742 optimized info should be defined
Vite Error, /node_modules/.vite/deps/pinia.js?v=72977742 optimized info should be defined (x2)

...

…and on and on and on goes these errors. For whatever reason, even though npm install has been run once just get to the point of running npm run dev, there needs to be a subsequent, specifically executed npm install @popperjs/core to install this particular dependency that throws this error.

So that’s it, that’s your fix. Cheers!

A Shiny New Vuejs v3 Web App Using & Deployed to Amplify/AppSync/Cognito

No cruft, let’s just start.

Continue reading “A Shiny New Vuejs v3 Web App Using & Deployed to Amplify/AppSync/Cognito”

The Fastest Way to Build a Quick Starter App with Express.js

Over the years I’ve used Express.js many times as a quick getting started example app. Since I often reference it I wanted to provide a short post that shows exactly what I do 99.9% of the time to start one of these quick Express.js reference apps. I’ve detailed in this post how to get started with Express.js the fastest way I know. There is one prerequisite, I’m assuming in this post you’ve already got Node.js installed. With that in mind, check out my installation suggestions for Node.js if you need to get that installed still. The other thing, is you’ll need to have git installed. On MacOS and Linux git is most likely installed already, if you’re on Windows I’ll leave that googling exercise up to you.

Create a directory and navigate into the directory.

mkdir quick-start-express
cd quick-start-express

Now in that directory execute the following command. Note, this command is available as of node.js 8.2.0.

npx express-generator
npm install

Inside that directory that you’ve navigated to, you’ll now have an Express.js skeleton app setup to run with the dependencies now downloaded with npm install. On MacOS or Linux run the following command to start the web app.

DEBUG=quick-start-express:* npm start

If you’re on Windows run the following command.

set DEBUG=quick-start-express:* & npm start

That’s it, one of the quickest ways to get a Node.js site up and running to start developing against!

If you’d like to dig in a bit deeper, here’s a great follow up post on creating APIs with Express. Give it a read, it’ll give you some great next steps to try out!

Cheers, and happy thrashing code!

The Method I Use Setting Up a Dev Machine for Node.js

UPDATED: April 4th, 2019 and again on March 17th, 2022

It seems every few months setup of whatever tech stack is always tweaked a bit. This is a collection of information I used to setup my box recently. First off, for the development box I always use nvm as it is routine to need a different version of Node.js installed for various repositories and such. The best article I’ve found that is super up to date for Ubuntu 18.04 is Digital Ocean’s article (kind of typical for them to have the best article, as their blog is exceptionally good). In it the specific installation of nvm I’ve noticed has changed since I last worked with it some many months ago.

Continue reading “The Method I Use Setting Up a Dev Machine for Node.js”

My Node.js Story

Once upon a time in a part of the tech universe far far away, there was a general consensus to block all JavaScript from browser execution. It was the way things were because JavaScript was seen as harmful. You see, the early miscreants of that time had used JavaScript to write all sorts of problematic code that would attack, steal, or otherwise undermine the data one sent across and received on the internet. This is the time I could have started learning JavaScript, but because of its horrid reputation I stayed far away and wrote C, C++, C#, Java, and event some RPG, COBOL, Pascal, and some other code. It was glorious, and the languages were beautiful in their own ways, while JavaScript was shunned by almost everybody in that tech universe! **

Today, things aren’t all that much different, but we make it easier for the whole horde of miscreant scripters to write problematic code in JavaScript. The difference is we allow it everywhere and just try to catch it and prevent execution. Thus, different, but the same, it’s a crazy world we live in.

I started picking up a little JavaScript at the tail end of 2007, when the “JavaScript: The Definitive Guide” was the top book to delve deeply into using JavaScript. It wasn’t another year until the seminal “JavaScript: The Good Parts” cut down the size of what one really needed to delve into by removing the cruft and focusing on the good parts. Slowly, JavaScript was finally starting to take shape as something useful.

Writing JavaScript at this time was a mutant challenge of having it look like Java while being organized like a trash pile of scripts that had no way to manage dependencies or otherwise. I mean, NPM was years away from existing, and really the concept of libraries in JavaScript seemed to be a foreign concept at the time.

2008 rolled around, “JavaScript: The Good Parts” came out, the changes started rippling through the industry and as traction started to mount. The penultimate event occurred the following year in 2009, which at the time almost nobody noticed. Dahl started Node.js at Joyent to enable server side JavaScript code use. At the time, many were flummoxed by the notion, weren’t confident in the single threaded event loop, and overall its release and the project continuing were in jeopardy from this point.

But the project continued and persisted!

Continue reading “My Node.js Story”