Lesson 8 · Node.js on IBM i — From RPG Developer to Modern IBM i Developer

Start the Tools Rental Project

Create the Node.js project we will use for the rest of the course, run its first small program, and put the source under Git control.

IBM iNode.jsGitnpmTools Rental

The short exercises in the first seven lessons helped us learn the environment. From this lesson onward, we will build one application and keep improving it until it is ready to test and deploy on IBM i.

The application will manage tools that a rental counter lends to customers. We will begin with a few values in JavaScript. Later, the same application will use Db2 for i, provide an API, enforce rental rules, record returns, and show the results in a browser.

There is no need to design the entire system today. In this lesson, we only need a clean project that runs and whose history is managed with Git.

What we are going to build

Our first useful version will answer four questions:

That gives us three natural areas of data: tools, customers, and rentals. We will design the Db2 tables in the next lesson rather than guessing at all their columns now.

Create a fresh project directory

Keep the earlier eraofi-node directory as a place for small experiments. Create a separate directory for the course project:

cd "$HOME"
mkdir -p tool-rental
cd tool-rental
npm init -y

Open package.json and reduce it to a few fields we understand:

{
  "name": "tool-rental",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "start": "node src/app.js"
  }
}

The application is marked private because it is not a package we intend to publish to the public npm registry.

Add the first source file

Create a src directory:

mkdir src

Create src/app.js with this small program:

const tool = {
  id: 101,
  name: 'Cordless Drill',
  status: 'AVAILABLE'
};

console.log(`${tool.id}: ${tool.name} - ${tool.status}`);

Run it through the npm script:

npm start

You should see:

101: Cordless Drill - AVAILABLE

For now, the tool exists only while the program runs. That is enough to confirm that the new project is set up correctly. Db2 will become the permanent home for this data in the lessons ahead.

Decide what belongs in source control

Create a file named .gitignore in the project root:

node_modules/
.env
*.log

This keeps installed packages, local secrets, and log files out of the repository.

When the application needs configuration, we will keep the real values in .env and provide a safe .env.example containing only the variable names and sample values. A real password, token, or private key should never be committed.

The files we do want to retain include:

Keeping these files together matters on IBM i just as it does on any other platform. A deployed application should be traceable to the exact source, SQL, and dependency lock file used to create that release.

Start the Git history

Check that Git is available, then create the repository:

git --version
git init
git add package.json src/app.js .gitignore
git status
git commit -m "Start tools rental project"

If Git asks for your name or email address, configure them according to your organization’s development standards. Do not invent a shared identity for the whole team.

Use git status before every commit. It gives you a chance to notice an environment file, generated output, or unrelated change before it becomes part of the project history.

A practical checkpoint

Before moving on, make sure all four commands succeed:

npm start
git status
git log --oneline -1
node --version

The working tree should be clean after the commit, and the application should still display the cordless drill.

We now have a small but real application rather than another disposable example. In the next lesson, we will design its Db2 for i data model before writing any table definitions.

References

Documentation and references used for this lesson.

← Return to Node.js on IBM i

Comments

Share your thoughts, questions, or real-world IBM i experiences related to this article.