Node.js 25 TypeScript, SQLite & Permission Model:
Complete Production Guide

1. Overview & Version Timeline

Node.js 25+ brings three transformative native features to the JavaScript runtime: native TypeScript support via built-in type stripping, built-in SQLite through the node:sqlite module, and the Permission Model for granular runtime security. This guide covers all three features in depth — from enabling Node.js TypeScript native execution without external dependencies, to using node:sqlite for zero-config database storage, to hardening applications with --permission and process.permission.has().

Key takeaway: As of Node.js 25+ (Current) and Node.js 24+ (LTS), all three features are stable and production-ready.

2. Native TypeScript Support (Type Stripping)

2.1 Enabling TypeScript in Node.js

There are two ways to run TypeScript code with Node.js:

Built-in type stripping works by default — just run:

# Run a TypeScript file directly (Node.js 22+)
node app.ts

# No flags needed — type stripping is on by default in v22+

To disable type stripping:

node --no-strip-types app.ts

2.2 How Type Stripping Works

Node.js executes TypeScript files by replacing TypeScript-only syntax with whitespace (preserving line/column numbers in stack traces). No type checking is performed — that's still the job of tsc in your editor/CI.

Key principles:

• No type checking at runtime — Node.js doesn't validate types, only strips them
• No source maps needed — whitespace replacement preserves line numbers
• No tsconfig.json reading — Node.js ignores tsconfig.json files entirely
• Lightweight — only erasable syntax is supported (no JavaScript code generation)
• Compatible with TypeScript 5.8+ (recommended minimum)

// This code runs natively in Node.js:
function greet(name: string): string {
  return `Hello, ${name}!`;
}

// The `: string` type annotations are stripped to whitespace
// Node.js sees: function greet(name) { return `Hello, ${name}!`; }

2.3 Supported File Extensions & Module System

Module system rules for .ts files:

• Add "type": "module" to your package.json to use import/export syntax
• Without "type": "module", .ts files default to CommonJS (require/module.exports)
• File extensions are mandatory in imports

// Correct:
import './helper.ts';
import { config } from './config.ts';

// Wrong — will fail:
import './helper';
import { config } from './config';

// Also correct for CommonJS:
const helper = require('./helper.ts');

2.4 TypeScript Features That Work / Don't Work

Error example when using unsupported syntax:

TypeError [ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX]: TypeScript features that require
JavaScript code generation are not supported. This file contains enum declarations
which require JavaScript code generation.

2.5 Importing Types (The type Keyword)

Due to how type stripping works, the type keyword is required in imports to distinguish type-only imports from value imports:

// ✅ Correct — will work:
import type { User, Config } from './types.ts';
import { createUser, type UserInput } from './user.ts';

// ❌ Wrong — will throw runtime error:
import { User, Config } from './types.ts'; // User is a type, not a value
import { createUser, UserInput } from './user.ts'; // UserInput is a type

Enable verbatimModuleSyntax in your tsconfig.json to enforce this behavior during development.

2.6 Recommended tsconfig.json Settings

For projects targeting Node.js 25+ with built-in type stripping:

{
  "compilerOptions": {
    "noEmit": true,
    "target": "esnext",
    "module": "nodenext",
    "rewriteRelativeImportExtensions": true,
    "erasableSyntaxOnly": true,
    "verbatimModuleSyntax": true
  }
}

2.7 Full TypeScript Support via Third-Party

For projects that need enums, decorators, or other unsupported features, use a third-party loader like tsx:

# Install as a dev dependency
npm install --save-dev tsx

# Run directly
npx tsx your-file.ts

# Or use with node --import
node --import=tsx your-file.ts

Other similar libraries: ts-node, ts-blank-space, sucrase.

2.8 Type Stripping in Dependencies & Non-File Inputs

Dependencies under node_modules: Node.js refuses to handle TypeScript files inside node_modules. This prevents package authors from shipping TypeScript instead of compiled JavaScript.

Non-file inputs:

• --eval and STDIN: Type stripping works, use --input-type to specify module system
• REPL: Unsupported
• --check: Unsupported
• inspect mode: Unsupported

Path aliases: tsconfig.json "paths" are not supported. Use subpath imports instead:

// package.json
{
  "imports": {
    "#utils/*": "./src/utils/*.ts"
  }
}

// Usage:
import { formatDate } from '#utils/date.ts';

3. Built-in SQLite (node:sqlite)

3.1 Overview

• Module: node:sqlite
• Since: Node.js v22.5.0
• Status: Stable in Node.js 24+ (LTS)
• API style: Synchronous (DatabaseSync, StatementSync)
• Engine: Built-in SQLite (no external dependencies, no native module compilation)

import { DatabaseSync } from 'node:sqlite';

const db = new DatabaseSync(':memory:');
db.exec(`
  CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    name TEXT NOT NULL,
    email TEXT UNIQUE
  );
`);

3.2 DatabaseSync Class

Constructor

new DatabaseSync(filename[, options])

Methods

3.3 StatementSync Class

Prepared statements created via db.prepare().

Usage Examples

// INSERT
const insert = db.prepare('INSERT INTO users (name, email) VALUES (?, ?)');
const result = insert.run('Alice', '[email protected]');
console.log(result.lastInsertRowid); // 1

// SELECT single row
const stmt = db.prepare('SELECT * FROM users WHERE id = ?');
const user = stmt.get(1);
console.log(user); // { id: 1, name: 'Alice', email: '[email protected]' }

// SELECT all rows
const allUsers = db.prepare('SELECT * FROM users').all();
console.log(allUsers); // [{ id: 1, ... }, { id: 2, ... }]

// Named parameters (using $, @, or : prefix)
const byEmail = db.prepare('SELECT * FROM users WHERE email = $email');
const user = byEmail.get({ $email: '[email protected]' });

3.4 Type Conversion Between JavaScript and SQLite

3.5 Transactions & Serialization

// Transaction (atomic, auto-rollback on error)
const insertUser = db.prepare('INSERT INTO users (name, email) VALUES (?, ?)');

const insertUsers = db.transaction((users) => {
  for (const user of users) {
    insertUser.run(user.name, user.email);
  }
});

insertUsers([
  { name: 'Charlie', email: '[email protected]' },
  { name: 'Diana', email: '[email protected]' },
]);

// Serialization (ensure sequential access)
db.serialize(() => {
  db.exec('INSERT INTO users VALUES (1, "Alice")');
  db.exec('INSERT INTO users VALUES (2, "Bob")');
});

3.6 Backup & Export

// Backup with progress
const db = new DatabaseSync('source.db');
db.backup('backup.db', {
  progress: (remaining, total) => {
    const pct = ((total - remaining) / total * 100).toFixed(2);
    console.log(`Backup: ${pct}%`);
  }
});

// Export entire database as Uint8Array
const data = db.export();
// data is a Uint8Array — write to file, send over network, etc.

3.7 Complete Code Example

import { DatabaseSync } from 'node:sqlite';

// 1. Create/open database
const db = new DatabaseSync(':memory:');

// 2. Create schema
db.exec(`
  CREATE TABLE projects (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    name TEXT NOT NULL,
    created_at TEXT DEFAULT (datetime('now'))
  );

  CREATE TABLE tasks (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    project_id INTEGER REFERENCES projects(id),
    title TEXT NOT NULL,
    done INTEGER DEFAULT 0
  );
`);

// 3. Insert with prepared statement
const insertProject = db.prepare('INSERT INTO projects (name) VALUES (?)');
const insertTask = db.prepare('INSERT INTO tasks (project_id, title) VALUES (?, ?)');

const projectResult = insertProject.run('My Project');
const projectId = projectResult.lastInsertRowid;

const addTasks = db.transaction(() => {
  insertTask.run(projectId, 'Design database schema');
  insertTask.run(projectId, 'Write API endpoints');
  insertTask.run(projectId, 'Test the application');
});
addTasks();

// 4. Query with joins
const tasks = db.prepare(`
  SELECT t.id, t.title, t.done, p.name as project
  FROM tasks t
  JOIN projects p ON t.project_id = p.id
  WHERE p.id = ?
`).all(projectId);

console.log(tasks);

// 5. Close
db.close();

4. Permission Model

4.1 Overview & History

The Node.js Permission Model is a runtime security mechanism that restricts what system resources a Node.js process can access.

Important caveat: The Permission Model implements a "least base" approach. It prevents trusted code from unintentionally accessing restricted resources, but does NOT guarantee security in the presence of malicious code. Malicious code can potentially bypass the model.

4.2 Enabling the Permission Model

# Enable the permission model (restricts ALL permissions by default)
node --permission app.js

# Error example when accessing a restricted API:
# Error: Access to this API has been restricted
#   code: 'ERR_ACCESS_DENIED',
#   permission: 'FileSystemRead',
#   resource: '/home/user/index.js'

When --permission is enabled, the following are restricted by default:

• File system access (node:fs)
• Network access
• Child process spawning
• Worker thread creation
• Native addons
• WASI access
• FFI access
• Inspector protocol

4.3 Runtime API: process.permission

process.permission.has(scope[, reference]) — Check if a permission is granted:

// Check if file system write is allowed
process.permission.has('fs.write');   // true | false

// Check if specific file is writable
process.permission.has('fs.write', '/home/refs/protected-folder');
// true | false

// Check file system read
process.permission.has('fs.read');    // true | false
process.permission.has('fs.read', '/home/refs/protected-folder');

process.permission.drop(scope[, reference]) — Irreversibly drop a permission at runtime:

import fs from 'node:fs';

// Read config at startup while we still have permission
const config = fs.readFileSync('/etc/myapp/config.json', 'utf8');

// Drop read access to /etc/myapp after initialization
process.permission.drop('fs.read', '/etc/myapp');

// This will now throw ERR_ACCESS_DENIED
process.permission.has('fs.read', '/etc/myapp/config.json');
// → false

// Drop child process permission entirely (no reference = whole scope)
process.permission.drop('child');

4.4 File System Permissions

# Allow all file system operations
node --permission --allow-fs-read=* --allow-fs-write=* index.js

# Allow specific paths
node --permission --allow-fs-read=/tmp/ --allow-fs-write=/tmp/ index.js

# Multiple paths
node --permission \
  --allow-fs-read=/tmp/ \
  --allow-fs-read=/home/user/.gitignore \
  index.js

4.5 Network, Child Process, Worker, Addon Permissions

node --permission \
  --allow-net \
  --allow-fs-read=/app \
  --allow-fs-write=/app/data \
  server.js

4.6 Configuration File Support

Permissions can be declared in a node.config.json file (requires --experimental-default-config-file):

{
  "permission": {
    "--allow-fs-read": ["/foo"],
    "--allow-fs-write": ["/foo"],
    "--allow-child-process": true,
    "--allow-worker": true,
    "--allow-net": true,
    "--allow-addons": false,
    "--allow-ffi": false
  }
}

4.7 Constraints & Known Issues

Limitations:

1. Permission Model is initialized after environment setup. Flags like --env-file or --openssl-config are evaluated before initialization and are NOT subjected to the model.
2. OpenSSL engines cannot be queried when Permission Model is enabled, affecting crypto, https, and related modules.
3. Explicit file descriptors via libuv bypass the permission model.
4. Symbolic links are followed even to locations outside the granted paths.
5. process._debugProcess() sends OS-level signals (SIGUSR1) to external processes and is NOT restricted by the Permission Model.

5. Migration Guide for Existing TypeScript Projects

5.1 Migration Strategy: Two Paths

5.2 Checklist for Type Stripping Migration

Step 1: Audit your TypeScript features — check for non-erasable syntax (enums, namespaces with runtime code, parameter properties, decorators).

Step 2: Update tsconfig.json with erasableSyntaxOnly and verbatimModuleSyntax. Run tsc --noEmit to verify compatibility.

Step 3: Fix import statements — add the type keyword where needed:

// Before:
import { User, Config, createUser } from './users.ts';

// After:
import type { User, Config } from './users.ts';
import { createUser } from './users.ts';

Step 4: Add file extensions to all imports:

// Before:
import { helper } from './utils/helper';

// After:
import { helper } from './utils/helper.ts';

Step 5: Replace tsconfig.json paths with subpath imports in package.json.

Step 6: Update package.json scripts — change "start": "node dist/index.js" to "start": "node src/index.ts".

5.3 Common Pitfalls

6. FAQ

7. Reference & Further Reading

Related Articles on maximov.by:

• Node.js Permission Model: process.permission.drop() in Node 26.3 — dedicated deep-dive into the Permission Model API
• Node.js 26: Temporal, V8 14.6, Undici 8 & Migration Guide — comprehensive Node.js 26 migration guide
• Promise.try Guide — new native Promise.try in Node.js 22+

Official Documentation:

• Node.js Modules: TypeScript — type stripping specification
• Node.js SQLite — node:sqlite API reference
• Node.js Permissions — Permission Model reference

Need to build a modern Node.js application with TypeScript, SQLite, and proper security? I'm a full-stack developer with deep experience in Node.js, TypeScript, and production architecture. Let's discuss your project.