Interactive Troubleshooter

Published: Sep 15, 2026

Node.js ERR_MODULE_NOT_FOUND After Move to ESM

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

This guide provides a comprehensive diagnostic tree to systematically resolve the Node.js ERR_MODULE_NOT_FOUND error after migrating from CommonJS to ECMAScript Modules (ESM). It covers mandatory file extension rules, directory index resolution failures, TypeScript path alias mappings, package exports fields, and dual CJS/ESM interop edge cases.

Full Diagnostic Tree & Step-by-Step Overview

Where is the ERR_MODULE_NOT_FOUND error originating from in your application?

Local project files imported using relative paths (e.g., import { foo } from './utils')
TypeScript compiled code or custom path aliases (e.g., import { foo } from '@/components/foo')
Third-party npm packages or node_modules dependencies
Mixed CommonJS and ESM module boundary interop or dynamic import() calls

How is the local relative import path formatted in the failing file?

The import path omits the file extension (e.g., './helper' instead of './helper.js')
The import targets a directory assuming implicit index.js resolution (e.g., './models')
The file uses .ts or .jsx extensions directly in import statements
The package.json is missing 'type': 'module' declaration in local sub-packages

Missing Explicit File Extensions in Relative ESM Imports

Solution:

Root Cause: Strict URL Specifier Resolution in ECMAScript Modules

Unlike CommonJS require(), which performs automatic file extension probing (.js, .json, .node), native ESM specifiers in Node.js follow strict browser-aligned URL resolution standards. When "type": "module" is defined in package.json, Node.js uses the default ESM resolver, which strictly mandates explicit file extensions for all relative (./, ../) and absolute (file://) module specifiers. Omitting .js causes the resolver to search literally for a file without an extension, throwing ERR_MODULE_NOT_FOUND.

# Diagnostic Verification:

Run your entry file with Node.js and inspect the stack trace:

bash
node index.js

Look for the error message detailing the missing exact file path:

text
Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/project/src/utils' imported from /project/src/app.js
Did you mean to import ../utils.js?

# Step-by-Step Fix:

1. Update Import Statements to Include Explicit Extensions:

Modify relative imports across source files to include full .js extensions:

javascript
     // Incorrect (CommonJS legacy format)
     import { formatDate } from './utils';

     // Correct (Native ESM format)
     import { formatDate } from './utils.js';

2. Automate Refactoring with Codemods:

For large codebases, use cjs-to-esm or ESLint rules (import/extensions) to append extensions automatically:

bash
     npx eslint --fix --rule 'import/extensions: ["error", "always"]' .

3. Verify Execution:

Re-run application execution to confirm resolution:

bash
     node index.js

# Prevention & Long-Term Monitoring:

Configure ESLint with eslint-plugin-import enforcing the import/extensions rule across all relative module imports.

Implicit Directory Index Resolution Failure in Native ESM

Solution:

Root Cause: Absence of Directory Index Resolution in ESM Specification

CommonJS automatically resolves ./directory to ./directory/index.js. The Node.js ESM specification intentionally dropped automatic directory index expansion to maintain alignment with web standards and prevent expensive file system checks over networks. When an import specifier targets a folder path without explicitly naming index.js, Node.js raises ERR_MODULE_NOT_FOUND because no directory match exists as a direct module entity.

# Diagnostic Verification:

Inspect the error stack trace to see if the target target path is a directory:

text
Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/project/services/user' imported from /project/app.js

Verify that /project/services/user is a folder containing an index.js file.

# Step-by-Step Fix:

1. Append Explicit /index.js to Directory Imports:

Update specifiers targeting directories to explicitly include the target file:

javascript
     // Incorrect
     import { userService } from './services/user';

     // Correct
     import { userService } from './services/user/index.js';

2. Alternative: Use Legacy Experimental Resolver Flag (Temporary Workaround):

If legacy behavior is required temporarily during migration, pass the experimental specifier resolution flag:

bash
     node --experimental-specifier-resolution=node index.js

*(Note: This flag is deprecated in newer Node.js releases and should not be used in production environments).*

# Prevention & Long-Term Monitoring:

Update team style guides and IDE auto-import templates to always append /index.js on folder-level module targets.

Incorrect File Extension Reference for Transpiled Modules

Solution:

Root Cause: Mismatch Between Source and Runtime Output Extensions

When writing ESM in TypeScript or JSX, developers often write import { foo } from './foo.ts' or leave off extensions. Because TypeScript does not rewrite specifiers during compilation (tsc), importing ./foo.ts attempts to load a literal .ts file at runtime, which fails under Node.js native ESM execution. Conversely, Node.js ESM requires the specifier to match the compiled output extension (.js or .mjs) even inside TypeScript source files.

# Diagnostic Verification:

Check the compiled JavaScript file in the output directory (dist/ or build/). If the source .ts file contains import './foo.ts' or import './foo', the compiled output contains identical text, causing Node.js to fail:

text
Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/project/dist/foo.ts' imported from /project/dist/app.js

# Step-by-Step Fix:

1. Use .js Extensions in TypeScript Source Files:

Write imports in TypeScript targeting the eventual JavaScript output extension:

typescript
     // Correct TypeScript ESM specifier targeting compiled file
     import { helper } from './helper.js';

2. Configure TSConfig Module Settings:

Ensure tsconfig.json uses modern module resolution settings:

json
     {
       "compilerOptions": {
         "module": "NodeNext",
         "moduleResolution": "NodeNext",
         "target": "ES2022"
       }
     }

3. Execute Compiler:

Run npx tsc and verify output in target destination.

# Prevention & Long-Term Monitoring:

Set "moduleResolution": "NodeNext" in tsconfig.json so the TypeScript compiler enforces mandatory output extensions during editing.

Missing Type Module Declaration in Package Scope

Solution:

Root Cause: Default CommonJS Scoping in Multi-Package Repositories

Node.js determines whether a .js file should be parsed as an ES Module or CommonJS file based on the nearest parent package.json file's "type" field. If a project or sub-directory package lacks "type": "module", Node.js treats .js files as CommonJS. When mixed loading occurs across packages without explicit .mjs extensions, relative ESM import graph linking fails with ERR_MODULE_NOT_FOUND or parse errors.

# Diagnostic Verification:

Check the nearest package.json relative to the failing module file:

bash
cat package.json

Observe whether "type": "module" is present or missing.

# Step-by-Step Fix:

1. Add "type": "module" to Root package.json:

Edit package.json to set ESM as the default scope parser:

json
     {
       "name": "my-app",
       "version": "1.0.0",
       "type": "module",
       "main": "index.js"
     }

2. Rename Individual CommonJS Files to .cjs (If Applicable):

If specific scripts must remain CommonJS (e.g., legacy config files), rename them from .js to .cjs.

3. Rename ESM Files to .mjs (Alternative for Mixed Repos):

If "type": "module" cannot be added globally, rename ESM files to .mjs to force ESM scope parsing.

# Prevention & Long-Term Monitoring:

Validate package.json structure during CI build runs to ensure package boundaries enforce consistent type settings.

How are you executing or transpiling your TypeScript / Alias paths?

Unresolved TSConfig path aliases (e.g., '@utils/math') at Node.js runtime
Using ts-node without experimental ESM loader configuration
Bundler / Transpiler (Build tools like tsc, esbuild, or SWC) dropping extensions
Node.js subpath imports ('#alias') misconfigured in package.json

Unresolved TSConfig Path Aliases at Runtime

Solution:

Root Cause: TypeScript Path Aliases Not Resolved by Native Node.js Resolver

TypeScript paths in tsconfig.json (such as "@/*": ["src/*"]) are purely compile-time constructs used by tsc for type checking. Neither tsc nor Node.js runtime replaces these alias paths with real relative paths during build or execution. When Node.js encounters import { foo } from '@/utils', it attempts to resolve @/utils as an installed npm package inside node_modules, failing with ERR_MODULE_NOT_FOUND.

# Diagnostic Verification:

Inspect the runtime error stack trace:

text
Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@/' imported from /project/dist/app.js

Confirm @/utils exists only in tsconfig.json paths and not as a physical package in node_modules.

# Step-by-Step Fix:

1. Use Node.js Native Subpath Imports (# Aliases):

Replace non-standard TS aliases with official Node.js subpath imports in package.json:

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

Update source code imports:

javascript
     import { formatDate } from '#utils/format.js';

2. Alternative: Resolve Aliases via tsconfig-paths / tsx Loader:

If using runtime execution loaders, run Node with explicit alias registration:

bash
     npx tsx src/index.ts

3. Use Build-Time Path Resolution Plugins:

If building with esbuild or swc, enable path alias resolution plugins (esbuild-plugins-tsconfig-paths) during compilation.

# Prevention & Long-Term Monitoring:

Prefer native Node.js Subpath Imports (#) over custom TypeScript path mapping to remain standards-compliant without extra build hooks.

Legacy ts-node Execution Missing ESM Loader Flags

Solution:

Root Cause: Default CommonJS Hooks in ts-node Execution Engine

By default, ts-node executes TypeScript files using CommonJS require() hooks. When running TypeScript code configured for native ESM ("type": "module" and "module": "NodeNext"), ts-node fails to intercept standard ESM loader hooks unless specifically instructed to run in ESM mode. Relative imports or dynamic import specifiers then fail to resolve, throwing ERR_MODULE_NOT_FOUND.

# Diagnostic Verification:

Execute your script with ts-node:

bash
npx ts-node src/index.ts

Observe failure during module loading:

text
TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts"
# OR
Error [ERR_MODULE_NOT_FOUND]: Cannot find module ...

# Step-by-Step Fix:

1. Enable ESM Loader Flag in ts-node:

Pass the loader flag explicitly to Node.js:

bash
     node --loader ts-node/esm src/index.ts

2. Configure ts-node Settings in tsconfig.json:

Add ts-node experimental ESM configuration directly inside tsconfig.json:

json
     {
       "ts-node": {
         "esm": true,
         "experimentalResolver": true
       },
       "compilerOptions": {
         "module": "NodeNext",
         "moduleResolution": "NodeNext"
       }
     }

3. Alternative: Migrate to tsx (Recommended Modern Alternative):

Replace ts-node with tsx (built on esbuild), which handles ESM resolution natively without loader flags:

bash
     npx tsx src/index.ts

# Prevention & Long-Term Monitoring:

Standardize local development runners on tsx for robust out-of-the-box ESM and TypeScript compatibility.

Build Tooling Stripping or Misconfiguring File Extensions

Solution:

Root Cause: Transpiler Output Mismatching Target Runtime Resolution

Bundlers and transpilers (like Babel, SWC, or rollup) can be configured to strip or alter file extensions during build steps. If the build step transpiles source code into native ES Modules (import/export syntax preserved) but leaves specifier paths extensionless, Node.js will fail to execute the output bundle without custom runtime hooks.

# Diagnostic Verification:

Check the generated build output files in your distribution directory (e.g., dist/index.js):

javascript
// Inside dist/index.js
import { sum } from './math'; // Missing extension in transpiled output!

Executing node dist/index.js throws ERR_MODULE_NOT_FOUND.

# Step-by-Step Fix:

1. Configure SWC / Babel to Preserve or Append Extensions:

Ensure build tool settings enforce extension generation. For Babel, use babel-plugin-add-import-extension:

json
     {
       "plugins": [
         ["babel-plugin-add-import-extension", { "extension": "js" }]
       ]
     }

2. Bundle Dependencies into Single Output (Esbuild Alternative):

Bundle output files into a single bundle to eliminate runtime relative resolution steps entirely:

bash
     npx esbuild src/index.ts --bundle --platform=node --format=esm --outfile=dist/index.js

# Prevention & Long-Term Monitoring:

Always test execution of compiled production artifacts in CI pipelines, rather than relying solely on development runtime behavior.

Package.json Subpath Imports Mapping Mismatch

Solution:

Root Cause: Invalid Specifier Pattern in package.json Imports Field

Node.js supports Subpath Imports via the "imports" field in package.json. All subpath import keys must start with the # prefix (e.g., "#dep" or "#utils/*"). If a subpath mapping key omits # or references a non-existent file path relative to the package root, Node.js fails to match the specifier and throws ERR_MODULE_NOT_FOUND.

# Diagnostic Verification:

Check your package.json for the "imports" definition:

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

Run node index.js with debug logging:

bash
NODE_DEBUG=module node index.js

Look for specifier mapping lookup failures in the trace output.

# Step-by-Step Fix:

1. Verify Leading Hash (#) Character:

Ensure all internal mapping keys begin strictly with #:

json
     {
       "imports": {
         "#internal/*": "./src/internal/*.js"
       }
     }

2. Include Exact Extensions in Mapping Targets:

Ensure target expansion paths explicitly include file extensions (.js):

javascript
     // Import statement in code
     import { helper } from '#internal/helper';

*Mapped target in package.json must match target file location exactly.*

# Prevention & Long-Term Monitoring:

Review the official Node.js Subpath Imports Documentation when structuring package alias architectures.

What type of third-party npm package is causing the resolution failure?

Package missing conditional 'exports' entry point in package.json
Deep subpath import into package internals (e.g., import 'lodash/cloneDeep')
Dual CommonJS/ESM package exporting incompatible default module syntax
Outdated npm package built exclusively for CommonJS without ESM wrapper

Package.json Exports Field Map Mismatch

Solution:

Root Cause: Dependency Package.json Missing ESM Export Condition

When a third-party npm package defines an "exports" field in its package.json, Node.js strictly restricts module loading to paths defined in that map. If the package does not explicitly define an "import" condition for ESM, or if "exports" maps only "require" for CommonJS, Node.js refuses to load the entry point when called from an ES Module, triggering ERR_MODULE_NOT_FOUND or ERR_PACKAGE_PATH_NOT_EXPORTED.

# Diagnostic Verification:

Inspect the installed package's package.json inside node_modules/<package-name>/package.json:

json
{
  "name": "some-library",
  "exports": {
    "require": "./dist/index.cjs"
    // Missing "import" condition!
  }
}

# Step-by-Step Fix:

1. Import Package via CommonJS Dynamic import() or createRequire:

Work around missing ESM export maps by leveraging CommonJS resolution:

javascript
     import { createRequire } from 'node:module';
     const require = createRequire(import.meta.url);
     const lib = require('some-library');

2. Patch Dependency via patch-package:

Add the missing "import" condition to the package's package.json and persist the fix:

json
     {
       "exports": {
         "import": "./dist/index.mjs",
         "require": "./dist/index.cjs"
       }
     }

Save patch locally:

bash
     npx patch-package some-library

3. Notify Maintainers:

Submit an issue or pull request to update the package's export map.

# Prevention & Long-Term Monitoring:

Audit third-party dependencies for native ESM support prior to adopting them in production projects.

Private Deep Subpath Import Blocked by Package Exports Map

Solution:

Root Cause: Enforced Package Encapsulation via Exports Field

In legacy CommonJS, consumers could import any internal file path from a package (e.g., import helper from 'pkg/lib/utils/helper.js'). In modern Node.js, if a package defines an "exports" object, all unexported internal paths are encapsulated and blocked. Attempting to import an unexported internal path results in ERR_MODULE_NOT_FOUND or ERR_PACKAGE_PATH_NOT_EXPORTED.

# Diagnostic Verification:

Check the terminal error output:

text
Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './lib/utils/helper.js' is not defined by "exports" in /project/node_modules/pkg/package.json

# Step-by-Step Fix:

1. Import Public Module Entry Point Instead:

Restructure your code to import exported top-level exports offered by the library author:

javascript
     // Incorrect
     import helper from 'pkg/lib/utils/helper.js';

     // Correct
     import { helper } from 'pkg';

2. Use Wildcard Export Paths (If You Maintain the Package):

If you are the author of the package, expose subpaths using wildcard mapping in package.json:

json
     {
       "exports": {
         "./*": "./src/*.js"
       }
     }

# Prevention & Long-Term Monitoring:

Refrain from importing unexposed internal paths from third-party npm packages.

Dual CJS/ESM Package Default Export Interop Mismatch

Solution:

Root Cause: Synthetic Default Export Mismatch in CommonJS Wrapping

When importing a CommonJS package from an ES Module using default import syntax (import pkg from 'cjs-package'), Node.js wraps the CommonJS module.exports object as the default export. If the CommonJS library was built with Babel or TypeScript and already assigned { default: ... } to module.exports, Node.js nests the export under pkg.default.default. Accessing pkg directly fails to locate expected properties, raising downstream module resolution errors.

# Diagnostic Verification:

Log the imported object in your ES module:

javascript
import pkg from 'cjs-package';
console.log('Imported payload:', pkg);

If output shows { default: [Function] } or [Module: null prototype] { default: { ... } }, a double-default wrapper mismatch has occurred.

# Step-by-Step Fix:

1. Destructure Named Exports or Access .default Property:

Extract named exports or access the underlying default payload:

javascript
     import pkg from 'cjs-package';
     const realPkg = pkg.default || pkg;

2. Use Named Imports via Static Analysis:

If Node.js detects CommonJS named exports via cjs-module-lexer, use named imports directly:

javascript
     import { specificFunction } from 'cjs-package';

# Prevention & Long-Term Monitoring:

Test dual CJS/ESM package consumption using Node.js directly rather than relying solely on bundler polyfills.

Legacy CommonJS Package Lacking Native ESM Entry Point

Solution:

Root Cause: Incompatible Loading Mechanism for Pure CommonJS Packages

Certain older npm packages rely heavily on CommonJS runtime features (such as require.resolve, module.parent, or dynamic conditional requires) that cannot be parsed by Node.js native ESM loaders. Importing these packages directly via static import syntax can trigger module resolution or execution crashes.

# Diagnostic Verification:

Check error stack traces when importing legacy packages:

text
ReferenceError: require is not defined in ES module scope
# OR
Error [ERR_MODULE_NOT_FOUND]: Cannot find module ...

# Step-by-Step Fix:

1. Instantiate CommonJS require using createRequire:

Create a local require function inside your ES module to load the legacy package using CommonJS rules:

javascript
     import { createRequire } from 'node:module';
     const require = createRequire(import.meta.url);

     const legacyLib = require('legacy-package');

2. Verify Execution:

Run the script; createRequire uses standard CJS resolution, bypassing ESM restriction checks.

# Prevention & Long-Term Monitoring:

Wrap legacy CommonJS dependencies in localized utility modules using createRequire to isolate non-ESM boundaries.

What dynamic import or module boundary error is occurring?

Dynamic import() call failing with relative path in string variable
JSON file import failing without import assertions / type attributes
Node.js core built-in module missing 'node:' scheme prefix
Symlinked package (npm link / pnpm) failing resolution in monorepo

Dynamic Import Path Resolution Failure with Variables

Solution:

Root Cause: Dynamic Specifier Evaluated Against Execution Working Directory

Dynamic import(specifier) calls resolve relative paths relative to the calling file's URL (import.meta.url), not the working directory (process.cwd()). If a dynamic import receives a string variable containing a path calculated from process.cwd() or an extensionless string, Node.js fails to locate the target file at runtime, raising ERR_MODULE_NOT_FOUND.

# Diagnostic Verification:

Inspect the dynamic import statement in code:

javascript
const moduleName = './utils'; // Missing extension
const mod = await import(moduleName);

Check runtime error message:

text
Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/project/utils' imported from /project/src/runner.js

# Step-by-Step Fix:

1. Construct Absolute File URLs for Dynamic Imports:

Use import.meta.url and URL constructors to construct precise, fully qualified file URLs:

javascript
     const modulePath = new URL('./utils/helper.js', import.meta.url).href;
     const mod = await import(modulePath);

2. Ensure File Extensions Are Appended to Dynamic Specifiers:

Always specify exact extensions in dynamically resolved string variables.

# Prevention & Long-Term Monitoring:

Avoid passing arbitrary runtime strings to dynamic import() without explicit URL sanitization and extension checks.

JSON File Import Failure Missing Import Attributes

Solution:

Root Cause: Missing Import Attributes for Non-JavaScript Modules

In standard CommonJS, JSON files could be loaded seamlessly via require('./data.json'). In native ESM, Node.js strictly forbids loading non-JavaScript files via standard import statements unless explicit Import Attributes (formerly Import Assertions) are declared. This security mechanism prevents arbitrary code execution vulnerabilities caused by servers serving unexpected content types. Importing JSON without with { type: 'json' } throws ERR_MODULE_NOT_FOUND or ERR_IMPORT_ATTRIBUTE_MISSING.

# Diagnostic Verification:

Inspect code attempting to import JSON:

javascript
import data from './data.json'; // Fails in ESM!

Terminal error output:

text
TypeError [ERR_IMPORT_ATTRIBUTE_MISSING]: Module "file:///project/data.json" needs an import attribute of type "json"

# Step-by-Step Fix:

1. Add Import Attribute Syntax to ESM Import:

Append the explicit with { type: 'json' } clause (Node.js 18.20+ / 20.10+ / 22+):

javascript
     import data from './data.json' with { type: 'json' };

2. Alternative: Load JSON via fs or createRequire for Older Node Versions:

Use node:fs or createRequire for backwards compatibility across older environments:

javascript
     import { readFileSync } from 'node:fs';
     const data = JSON.parse(readFileSync(new URL('./data.json', import.meta.url)));

# Prevention & Long-Term Monitoring:

Consult the Node.js Modules Documentation for updated specs regarding JSON module loading.

Node.js Core Module Built-In Scheme Mismatch

Solution:

Root Cause: Built-In Core Module Shadowed or Unresolved

When importing Node.js built-in core modules (such as fs, path, stream, or crypto) inside an ES Module, omitting the explicit node: protocol prefix can lead to resolution failures if a local folder or installed npm package shares the name of the core module (e.g., a local ./path folder or legacy crypto package in node_modules). Node.js ESM resolvers prioritize explicit core protocol URIs.

# Diagnostic Verification:

Inspect module import statements:

javascript
import fs from 'fs'; // Can collide with local/npm packages

Trace logging shows Node attempting to look up node_modules/fs/package.json instead of loading the internal C++ core binding.

# Step-by-Step Fix:

1. Prefix All Core Node.js Built-Ins with node::

Explicitly specify the node: protocol URI across all built-in module imports:

javascript
     import fs from 'node:fs';
     import path from 'node:path';
     import { EventEmitter } from 'node:events';

2. Remove Outdated Polyfill Packages from node_modules:

Uninstall legacy npm stub packages (like path or util) that shadow native Node.js implementations:

bash
     npm uninstall path fs util crypto

# Prevention & Long-Term Monitoring:

Enable the ESLint unicorn/prefer-node-protocol rule to enforce node: prefixes across all built-in module imports automatically.

Symlinked Workspace Package Resolution Failure in Monorepos

Solution:

Root Cause: Realpath Resolution Escalating Outside Project Root Scope

In monorepo setups using symlinks (such as npm link, pnpm, or Yarn workspaces), Node.js by default resolves symlinks to their real physical path (realpath) on disk before performing module lookup. When an ES Module inside a symlinked package imports a dependency, Node.js searches for dependencies relative to the real location of the symlinked package rather than the main project's node_modules directory, causing ERR_MODULE_NOT_FOUND.

# Diagnostic Verification:

Check if the target package is a symlink:

bash
ls -la node_modules/my-linked-package

Run your application with symlink preservation enabled:

bash
node --preserve-symlinks index.js

If --preserve-symlinks resolves the issue, realpath resolution was stepping outside the workspace tree.

# Step-by-Step Fix:

1. Pass --preserve-symlinks Flag to Node.js Runtime:

Instruct Node.js to resolve modules relative to symlinks rather than real paths:

bash
     node --preserve-symlinks index.js

2. Configure NODE_OPTIONS in Environment:

Export the flag in shell or CI environments:

bash
     export NODE_OPTIONS="--preserve-symlinks"

3. Use Workspace Protocols for Monorepo Dependencies:

Configure package workspace bindings in package.json:

json
     {
       "dependencies": {
         "@my-org/shared": "workspace:*"
       }
     }

# Prevention & Long-Term Monitoring:

Use modern monorepo package managers (pnpm or Yarn v4) that manage module resolution structures without breaking standard ESM lookup rules.

Related Diagnostic Guides

Python Virtual Environment Broken After Python Upgrade

Docker Build Context Too Large: .dockerignore Diagnostic

VS Code Remote SSH Keeps Disconnecting: KeepAlive Fix

Git LFS Pull Failed: Authentication and Bandwidth Fix

Systemd Service Failed to Start: journalctl Diagnostic

Embed Guide on Your Website