Some of you may know that this site is hosted on Netlify.  But recently I was experiencing weird issues with different environments and the source not always building consistently across multiple machines.  Obviously the build system that runs when Netlify detects a change to the source code or a triggered build is fired when I’ve created a new article, would be another system that needs to build the repository.  After a lot of digging, I started to realize that this solution only optimally runs on a very specific version of Node and NPM.  

## Specifying Engine Details in NPM

So I needed a way to instruct those that are trying to build my repository for this site, to tell it specifically what version of npm/node to use.  I found that this is quite easy to do, but requires some configuration in your `package.json`:


```json
{
  "engines": {
    "node": ">=0.10.3 <15",
    "npm": ">=1.0.20"
  }
}
```

For more information about this, you can refer to the [documentation available from NPM](https://docs.npmjs.com/cli/v8/configuring-npm/package-json#engines).

Once you’ve configured the engines in your package.json, you’ll also want to look at creating a `.npmrc` file to control when this engine definition is enforced (otherwise its just optional and will display a friendlier warning in the console when you try to do a build, vs blocking the build if it’s set to strict).  

```json
engine-strict=true
```

## What about ensuring Netlify builds with the correct version?

So the details that we specified above are great, especially if we want to ensure every developer working on our project is using the same requirements to run and work on the solution.  In fact, I would say that if you are starting a new project, you will almost certainly want to provide this detail to ensure everyone is using the correct version.  But even after making those changes above, I found that the Netlify builds were still using the default `12.x` node version to do my builds for my project.  So what am I missing?

Well, it turns out I needed, at least for Netlify, to create a new file `.nvmrc`.  Now NVM (Node Version Manager), if you’ve never used this before, this is also an almost necessity if you are developing with node locally because each project that you are building locally could easily require a different node or npm version.  NVM solves all of those issues by managing multiple versions of Node on your machine.  If you need to switch to a different node version, you can simply either install that version using `nvm install 12.x.x` or whatever the version may be, but also you can use the `nvm list` command to see a list of all the installed versions of npm/node that NVM is managing for you. 

But either way, it appears that the Netlify build is using NVM as well to manage which version of node/npm to run.  So now it’s actually quite easy to just specify the version we need in our `.nvmrc` file:

```json
v14.16.1
```

Once I committed that change, I was now seeing that the Netlify builds were downloading if the build agent hadn’t already installed that version, and if it had, it would go ahead and use the version that I specified.  Pretty neat stuff, so at the end of this, I can now ensure that local development is using the correct versions of npm/node, as well as the Netlify build servers.  Now I can take on a feature task in my repository to ensure it works with the latest lts of node/npm and then update everything to match that version.

## Extra Credit

So I was thinking about how this behavior of using `nvm use` works for our Netlify builds but for some reason it doesn’t seem to be working for `nvm-windows`.  After some quick googling, I came [across this post](https://gist.github.com/danpetitt/e87dabb707079e1bfaf797d0f5f798f2), provides an alias work around which gives the same outcome, since this functionality of the `nvm use` command, picking up the current `.nvmrc` file is only supported in Linux.  So definitely something worth adding, so the next time you work on a node/npm project, you can just run your simple alias command, and start using the specific versions of both engines immediately.  Pretty cool!

How to Change the Node Version for Netlify Builds


I've been curious about this topic for quite some time.  As a Sitecore developer, I knew it was easy to build a .Net core CLI (Command Line Interface) application, and in fact, there is already one available from Sitecore that was extensible.  Technically I would say JSS falls into this category as well and is Node-based.  But before we get into this topic at a deeper level, I wanted to briefly talk about why I wanted to learn this and potentially build my own Node-based CLI.


So for Sitecore development in general, everything has always been done in .Net.  For a .Net developer wanting to run a CLI, it seemed only natural for them to either already have the .Net runtime to run the CLI or for them to download the required framework.  But I wondered is that feasible for a frontend developer?  Now sure to run a Node CLI, you have to have node, but I would argue that there are way more developers in general running Node today than running .Net runtime.  And especially if you are targeting the typical Frontend developer, they might not even know much about .Net at all.  So it just seemed like a good idea to build a CLI, potentially for Sitecore (but I might take it further in the future) using Node so that more Frontend developers don't have to jump through the .Net hoops.  Frontend developers used to the Javascript Frameworks of today, can stick to the tools they are used to, while .Net developers could theoretically continue to use the .Net CLI.

So that is the premise behind this curiosity, but I wasn't sure it was feasible yet, and probably still won't know in the immediate term how feasible it really is, but I figured I'd write about my journey nonetheless.

## Running a CLI with Node

So before I start building a CLI, I wanted to talk a little bit about the nuances of running a CLI.  If you are a .Net developer, or not that familiar with NPM, this section is for you.  Now first off it's important to know the differences between Node and NPM.  Node is simply the runtime, allowing you to write Javascript and have that run on your machine (similar to how the .Net runtime works for .Net), while NPM is nothing more than a place to store your node scripts and allow users to consume them (similar to Nuget).  We are going to use NPM to distribute and run our Node CLI, which we’ll cover how to take our simple CLI and use Github Actions to deploy that out to NPM.  There are a couple of ways a user can run a CLI with NPM.  They could install an NPM package globally and run it with a simple npm command:

```javascript
> npm i speed-test -g

> speed-test
```

Now that it's been installed locally you can simply just run `speed-test` in your command line to run a speed test (this is just an example of a CLI you can use).  This method of running a CLI is great if you need to run this CLI often.  An example of a CLI you may run multiple times could be `yo` which runs Yeoman which is a Node/Javascript-based templating engine.  But what if you just want to run something once?  Well as of version 5.2.0+ of npm, it now includes something called `npx`, which just gives you the ability to run any npm package one time.  This is quite useful for running CLI commands.  An example of this is when you want to create a `React` project, you might run the following command:

```javascript
> npx create-react-app my-react-project
```

So this npx command will execute the npm package called `create-react-app` which will be useful for generating the needed starter kit template to run React.

## Building our Node CLI application

So now that you know how you can run a CLI application based on Node, let's explore how you would create your first node CLI application.  It’s quite easy to get started, you’ll likely need a GitHub repository (especially if you want to use Github actions to deploy to npm covered in a future article), or if not, you’ll need a folder for where your application will begin to be built.  If using a repository, clone this repository locally, this is where I’ll begin this topic.  If you are not sure how to clone a repository, definitely check out this topic where I covered how to use the CLI to run common git actions.  If you want to skip ahead, you can navigate directly to the repository here.

So once we have a blank repository, we need to start by initializing Node by running the following command:

```javascript
> npm init -y
```

And then that will create a package.json file with all the default options.  If you would like to choose options as you go, just leave off the `-y` flag, and then you’ll be required to answer the questions, or just press enter to go with the default options.

We next should install some common CLI packages that might be useful in our CLI application.  Obviously, not all of these are required, but most with be helpful.

- Commander: This package will make it easier with several helpful options for commands, options, etc.
- Chalk: This allows us to output colored messages.

To install these, just run the following command:

```javascript
> npm i commander chalk
```

Once those are installed, I’ll go ahead and create a `src` folder that will contain our code for the CLI application.  I also plan to use typescript for this application, so to initialize typescript, in the root, also run the following commands to get setup:

```javascript
> npm i typescript@latest @types/node

> npx tsc --init
```

These steps will create a tsconfig.json in your root directory and tells typescript how to compile the typescript and output javascript.  Now let's jump into some of the changes you’ll need to make to your `package.json` file.  At any point, you can refer to this [repository on GitHub](https://github.com/dylanyoung-dev/first-node-cli) to see the final product.

```javascript
{
  "name": "first-node-cli",
  "version": "1.0.0",
  "description": "Just a play repo that I'll use in my blog series",
  "main": "index.js",
  "scripts": {
    "build": "tsc",
    "start": "ts-node ./src/bin/index.ts",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/dylanyoung-dev/first-node-cli.git"
  },
  "bin": {
    "test-cli": "./src/bin/index.ts"
  },
  "author": "",
  "license": "ISC",
  "bugs": {
    "url": "https://github.com/dylanyoung-dev/first-node-cli/issues"
  },
  "homepage": "https://github.com/dylanyoung-dev/first-node-cli#readme",
  "dependencies": {
    "@types/node": "^18.6.1",
    "chalk": "4.1.2",
    "commander": "^9.4.0",
    "typescript": "^4.7.4"
  }
}
```

You’ll need to add two `scripts` that are missing, one for the Typescript build `"build": "tsc"` and then another one for start `"start": "ts-node ./src/bin/index.ts"` these we’ll use later.  Then you’ll also need to create a bin definition:

```javascript
"bin": {
	"test-cli": "./src/bin/index.ts"
}
```

This is so that when we type in a command into the command line, it’ll know what phrase to use to trigger the command `test-cli` and then what file to run.

Now that’s it for the package.json, now let's create two files.  One called index.ts (`/src/bin/index.ts`) with the contents below.   This is the primary starting point for the application, where you can place other imports if you were building more than a simple “Hello World” repository.  

```javascript
#!/usr/bin/env node
import { Command } from 'commander';
import * as packageJson from '../../package.json';
import { sayHello } from '../test';

const program = new Command();

program.version(packageJson.version)
    .command('say-hello')
    .description('A simple CLI tool to say hello')
    .action(() => {
        sayHello();
    }
    )
    .parse(process.argv);
```

This code really shows how the `commander` npm package really helps with the Node CLI, because you can specify a command, in this case, `test-cli say-hello` would be used to now run the action `sayHello();`. You can also provide options or arguments here as well if your CLI needs user-provided data.

You’ll also need to create an `/src/test.ts` file, which will contain our sayHello function which our commander function calls into.  At this point, we just output our Hello World, using the npm package for chalk which allows us to use different colors in our command line.

```javascript
import chalk from 'chalk';

const sayHello = () => {
  console.log(chalk.green('Hello World!'));
}
```

## Testing Your CLI

Once you’ve completed writing your application, there are a couple of different wants to test it out, but I found the following one of the better ways, plus if you are creating some form of CLI that works with a separate folder on your machine, I found this is the closest to the experience you would have if you pulled the package from NPM directly.

You’ll first need to build your NPM package, and in a previous step, we created an NPM script called `build` which we can use to facilitate the Typescript build process.  We can run the following command below to run the build script.

```bash
> npm run build
```

Then once it’s built, you can then run an NPM link command, which basically links the global npm command for this NPM package to this local folder, so that we can run the `test-cli` anywhere, and in any folder.

```bash
> npm link
```

So once you’ve run that command, you should now be able to run the following command anywhere else globally that you would like, and your output should be a green `Hello World` message.

```bash
> test-cli say-hello 
```

Well that completes today’s content.  I will continue this post in my next article, where I will cover how to create a basic CI/CD process using Github Actions to publish our CLI out to NPM.  This will then allow us to run npx test-cli or to install it globally or locally for various needs in a specific application.

Building Your First Node JS CLI

So in my journey with this new domain, one challenge that was presented to me, was the need to 301 my existing sitecoremaster.com domain to my new blog.  This used to be an easy proposition in the realm of .Net.  But lets explore my journey to the answer I finished with.

But like everything as I've transitioned from .Net to Next.js/React development, it requires a complete shift.  First I explored handling this in Next.js.  It's complicated because Next.js handles server side functionality as well as client side.  But in my case Next.js is only handling the Static Site Generation (SSG) for the Jamstack approach, running through Netlify.

## Next.js

So my first thought was that this is something that Next.js can handle, because I know it has the capabilities of handling Server side generation.  I also know there is features to handle 301's, but it turns out, this can only handle page 301 redirects, not necessary anything related to the tld redirect.

So for example in your `next.config.js` you could define something like this:

```
module.exports = {
  async redirects() {
    return [
       { source: '/about', destination: '/', permanent: true },
    ]
  },
}
```

And then essentially define in that array as many redirects as you want to handle.  You can even include path matching, in case you wanted to redirect where your blog articles sit on your website.  Quite powerful for custom scenarios, but for my scenario, this just didn't quite do the job, since I had a whole different domain redirecting into my current one.

Also most of my site is Statically generated using Next.js's Static Site Generation (SSG) functionality.  And this is even more of an issue when you introduce Netlify, which is really meant to handle SSG sites versus a node based environment.  In other words, you can't easily run server side applications on this platform (unless you use serverless functionality, but I don't want to get into that topic for today's video).

## Netlify

So after further research it dawned on me that I needed to essentially revert back to the old .Net/IIS days where I would handle this in a redirects config in the web.config.  Even though you are using files, what you are really doing is instructing IIS to handle the redirects and therefore you have more control.

So Netlify to the rescue, however some steps were needed to get to the final solution.  First off, I needed to point my old Sitecoremaster.com site to Netlify.  It's actually quite easy to setup custom domains in Netlify (https://docs.netlify.com/domains-https/custom-domains/).  I needed to point Sitecoremaster to the same site definition in Netlify.

![Netlify Domain Configuration](https://cdn.sanity.io/images/lanua4su/production/f26a5042290840ea49569787e9c142d450a4fe48-958x716.jpg)

As you can see, I have the domains attached.  Once any DNS information is tied up, you should start seeing that the new domain that you want to 301 is now pointing also to the new location.  So now, you just need to handle the 301.  After poking around the documentation, I discovered that most of this is or well could/should be handled by your netlify.toml file.  It was actually quite easy to setup, although I tried to find a way to do the canonical version with wildcards, which for some reason didn't want to work correctly.

This is essentially the changes that I made: (https://github.com/dylanyoung-dev/website/blob/main/netlify.toml#L6:L16)

```
[[redirects]]
from = "https://www.sitecoremaster.com/*"
to = "https://dylanyoung.dev/"
status = 301
force = true

[[redirects]]
from = "https://sitecoremaster.com/*"
to = "https://dylanyoung.dev/"
status = 301
force = true
```

Basically redirecting `www` or `non-www` urls all back to the same `https://dylanyoung.dev`.  

Backend Development

How to Change the Node Version for Netlify Builds

Building Your First Node JS CLI

Configuration of 301 Redirects with Netlify and Next.Js