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.
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:
- Which tools are available?
- Who has rented a tool?
- When is it due back?
- Has it been returned?
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:
- JavaScript source
package.jsonpackage-lock.jsonafter dependencies are installed- SQL scripts and database changes
.gitignoreand.env.example- tests and operating instructions
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.

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