SublimeText 4 – SublimeLinter and SublimeLinter-eslint are not working

by

Summary

SublimeLinter-eslint integration failed after a Windows 11 reinstall for a user running SublimeText 4 (build 4200) and Node.js 24.13.0. Despite successful package installations via Package Control and functional command-line eslint, the editor showed no linting UI or menu items. The root cause was a missing Node.js PATH environment variable propagation to the SublimeText host process, compounded by a misunderstanding of Package Control’s managed installation directories. The issue was resolved by ensuring SublimeText inherits the system PATH correctly, typically requiring a full restart of the editor after PATH changes or explicitly defining the node_path in SublimeLinter settings.

Root Cause

The failure stems from environment isolation between the operating system’s shell and the SublimeText application process.

  • Process Environment Inheritance: Windows applications launched from the taskbar or Start menu do not always inherit the latest PATH environment variables immediately. After a reinstall, or if SublimeText was running during the Node.js installation, the editor likely possesses an empty or outdated PATH variable.
  • Executable Resolution: SublimeLinter-eslint spawns a shell to execute eslint. If the SublimeText process cannot resolve the location of node or eslint binaries, the linting process silently fails or fails to start entirely.
  • Package Directory Confusion: The user’s observation that “Preferences => Browse Packages” does not show SublimeLinter folders indicates a confusion between the user Packages directory and the Installed Packages directory. SublimeText typically stores installed packages as .sublime-package zip archives in Installed Packages, not as loose folders in Packages unless manually cloned.

Why This Happens in Real Systems

Stateful environment variables are a common source of friction in development environments.

  • Session Stickiness: Windows environment variables are cached in the registry and only refreshed for new processes. If you change the PATH (e.g., installing Node.js) and do not restart every application that might need it (including SublimeText, terminal emulators, and IDEs), the application remains “blind” to the new paths.
  • Orphaned Configurations: In a catastrophic system failure (reinstall), npm global paths (C:\Users\<User>\AppData\Roaming\npm) are often restored to the system PATH manually or by installers, but the verification step (restarting the GUI tool using them) is frequently skipped.
  • Silent Failures: Linters are “reactive” tools. Unlike a compiler that runs explicitly, a linter runs in the background. If the underlying executor fails to find the binary, it usually suppresses the error to avoid spamming the UI, leaving the developer with a “silent” failure.

Real-World Impact

  • Zero Visibility: The developer loses immediate feedback on syntax errors, style violations, and potential bugs, effectively coding “blind” in modern JavaScript environments.
  • Context Switching: The workflow is broken, forcing the developer to switch to the terminal to run eslint manually for every file or change, destroying flow state.
  • Configuration Paranoia: The user is forced to guess at the problem, leading to unnecessary reinstalls of packages (eslint, SublimeLinter, SublimeLinter-eslint) and manual unzipping, which can corrupt the Package Control registry.

Example or Code

Since the issue is environmental, the fix is best demonstrated by explicitly configuring SublimeLinter to locate the Node.js binary, bypassing the unreliable system PATH.

{
    "debug": true,
    "node_path": "C:/Program Files/nodejs/node.exe",
    "paths": {
        "windows": [
            "C:/Users//AppData/Roaming/npm"
        ]
    }
}

(Note: Replace C:/Program Files/nodejs/node.exe with the actual path where Node is installed, and <YourUsername> with your Windows username.)

How Senior Engineers Fix It

Senior engineers diagnose process environments rather than just “broken tools.”

  • Verify the Environment: Before touching the editor, they open a new terminal (PowerShell/CMD) and run where node and where eslint to confirm paths are valid. Crucially, they then verify that SublimeText sees these paths by using the View > Show Console menu and checking os.environ['PATH'] (via Python bridge if possible) or simply restarting the computer to force a full environment reload.
  • Explicit Configuration: Instead of relying on the system PATH (which is fragile), they modify the SublimeLinter user settings to point directly to the Node.js executable via the node_path setting. This decouples the editor’s linting capability from the OS environment state.
  • Debug Mode: They enable the "debug": true setting in SublimeLinter to capture the exact shell command being executed and the error message returned, turning a silent failure into a visible log.

Why Juniors Miss It

Mental Model Mismatch is the primary reason juniors struggle with this.

  • Shell vs. GUI: Juniors often understand that “npm install works in my terminal” implies “everything works.” They fail to realize that GUI applications like SublimeText run in a separate process with its own environment state that may not match the terminal session.
  • Installation vs. Availability: They assume that because eslint exists on the disk, it is “available.” They miss the nuance of discoverability (PATH resolution).
  • UI Expectations: When the Linter menu is missing, they assume the package is uninstalled, leading to the cycle of reinstalling. They don’t realize the menu often only populates after a linter successfully initializes on a specific file type.