Published on

My Experience Updating My NextJS Business Site to Fix NPM Packages

Last Modified on
Last modified on
Authors
Builder fixing window frame
Photo by Erik Mclean on Unsplash

I just finished updating my (this) business site in order to fix npm packages (of their current versions) I am using. It was not a long ride, but it definitely was a bit of a wild one.

There were a few packages with vulnerabilities that I wanted to remove. I first tried updating everything to the latest version. I broke the site doing that, and ended up discovering that the main culprit preventing me from at least updating Next.js and React for starters so that I could use the cool new features in Next.js 13 (they are already releasing v14 soon!) is esbuild. As great as esbuild is supposed to be for mdx, it is also really complex behind the scenes and hard to “update”.

However, there is such a thing as fixing existing versions of packages. And thankfully, that is exactly what Timothy Lin (aka timlrx On Github) did with his tailwind-nextjs-starter-blog template which I used to build this site.

Previously, I would visit to see if there had been any major changes that I would want to incorporate into the site, but there did not seem to be any. When I started to try and update the site packages myself (and was unsuccessful), I decided to clone the repository and test it out locally.

Some pretty important changes (to me anyway) Were made to the repository. Packages which needed fixing were addressed and almost totally fixed! I tested everything out in my cloned version of the repository locally on my machine, and brought in the code changes I had in my repository, bit by bit, to see what would happen. AND I did this all in Node.js 18.12.1. It is important to note that up till this time I had to work with my version of the repository in 16.17.0. But after the fixes that were made to the site (primarily in the package-lock.json), I was able to work with it in Node.js 18.12.1, which is the version I am currently working with.

After I had replicated my site in the cloned, updated version of Timothy’s tailwind-nextjs-starter-blog template, and in Node.js 18.12.1, I then replicated what I had there in my own repository of this site. The way I achieved that was to replace the contents of my package.json with that of the cloned repository, and I replaced the contents of my package-lock.json with that of the cloned repository. Updating the package-lock.json was key. Then, whatever other packages were missing that I had been using, I just re-installed using the same versions that I had on remote. There was no issue with those. And lastly, remember to remove your node_modules folder and then reinstall. So first:

rm -rf node_modules

At the root of your project directory where your node_modules folder resides. Then run npm i in order to reinstall the packages which are present in the package.json file. There may be some packages you have subsequently installed that would then not be present in your project on re-installation. So between throwing errors when running npm run dev (running your Next.js project in development mode) or errors being _highlighted _in the text editor itself, technically you would be able to replicate your former instance of your project. I do advise that you take the approach of first cloning the updated template repository and replicating your project with the fixed packages in place. Then, when everything works there, you can integrate those changes into your existing project repo. The process will be a lot faster, and with much less headache! I learned the hard way, but that does not mean you have to go through that grueling process just because I did!

It was also a good time to get rid of packages_ and _configurations_ which I was _never_ going to _use_ that I had _installed_ along the _way***.

The one thing that I did initially have issue with simply because I had forgotten that it had been an issue when I first started building the site, was that the example posts which came with the template were different in the included frontmatter from the frontmatter I ended up with. And I had “temporarily” forgotten about that. Why? In my site, I had kept those posts set to draft: true (God only knows why), but in the clone, they were set to draft: false. So when I brought in my configurations and code changes to the cloned repository, the app kept on throwing errors related to those added features. Namely, I added the images property to my frontmatter and a categories property as well. The template did_ not support_ these features out of the box, so that is why the errors kept on occurring.

When I finally remembered why this was happening with the help of helpful error messages in the Terminal console telling me_ where_ these errors were taking place, especially on build, I remembered that I had the same exact issue(s) when first building the site and adding new features to the template. So I removed those example posts entirely!

Remember this if ever you encounter similar behavior when updating your template(s) in any way, and especially if you are updating Timothy Lin’s tailwind-nextjs-starter-blog template. It is a great template, and you can learn much about TailwindCSS, MDX, and Next.js by implementing it in a project or site. That is what got me into learning about TailwindCSS and Next.js! I have since used both Next.js and TailwindCSS in other projects (not the template), so coming back here to tweak the site here and there was quick and (relatively) easy in the end!

Feel free to check out the (public) repository of this site on Github. And please do check out the Github repository for Timothy Lin’s tailwind-nextjs-starter-blog template. I have included a link to both within the Related Resources section below.

Happy TailwindCSS and Next.jsing!