is-valid-path

is-valid-path is a minimal Node.js utility from the jonschlinkert glob-matching ecosystem (alongside is-glob, micromatch, and parse-glob) that answers one narrow question: is this string a plain, usable file path, or does it contain characters that make it invalid as a literal path? It returns false for glob patterns, extglobs, regex-style character classes, brace expansions, and non-string input, and true only for clean, literal paths like abc/def/ghi.js.

Under the hood it delegates entirely to the companion package is-invalid-path, inverting its boolean result. The whole library is a single exported function with no configuration, options, or async behavior — install it, call it with a string, get a boolean back.

What You Get

• A single default-exported function, isValid(str), returning a strict boolean
• Detection of glob syntax (*, **, ?) that would make a string invalid as a literal path
• Detection of brace expansions ({a,b}, {a..z}) and extglob syntax (@(), !(), +(), *(), ?())
• Detection of regex-style character classes ([a-z], [^abc]) and alternation groups ((aaa|bbb))
• Safe false fallback for non-string input (undefined, null, objects, arrays) instead of throwing

Common Use Cases

• Guarding a file-system operation so it only runs against a literal path, not an accidental glob
• Validating user- or config-supplied path strings before passing them to fs calls
• Distinguishing a literal path argument from a glob pattern in a CLI tool that accepts both
• Pre-filtering path-like strings in a build script before they reach a globbing library

Under The Hood

Architecture The entire package is a single-file, single-function module: index.js requires the companion package is-invalid-path and returns the logical negation of its result. There is no internal layering, no class hierarchy, and no state — it is a pure delegation wrapper, so understanding this package means understanding its one dependency’s character-matching rules rather than any logic that lives in this repo itself.

Tech Stack Written in plain ES5 CommonJS JavaScript with a single runtime dependency (is-invalid-path@^0.1.0) and mocha/should as dev dependencies for testing. There is no build step, no transpilation, and no bundler config — package.json declares node >=0.10.0 as the only engine constraint, consistent with the library’s 2015 origin.

Code Quality A test.js file using Mocha and the should assertion style exercises a wide range of inputs — valid literal paths, glob wildcards, brace expansions, extglobs, regex character classes, and non-string values — giving reasonable behavioral coverage for such a small surface area. There is no CI configuration in the repository and no type definitions, so correctness relies entirely on the local test suite and manual review rather than automated typing or continuous checks.

API Design The developer experience is about as low-friction as it gets: one function, one string argument, one boolean return, no options object and no async handling to reason about. That simplicity is also its main limitation as a piece of documentation — the README shows usage examples but there are no JSDoc annotations, TypeScript types, or a docs directory, so callers must infer edge-case behavior (like the false fallback for non-strings) from the test file rather than from inline documentation.