Lodash toPath Internal Utility

Common errors

• SyntaxError: Unexpected token 'export' (or similar 'require is not defined')

  cause Attempting to use ES module `import` syntax for `lodash._topath` (a CommonJS package) or using `require` in an ES module without proper configuration.
  fix For `lodash._topath` (v3.x), always use `const toPath = require('lodash._topath');`. Ensure your environment supports CommonJS or configure transpilation correctly if mixing module types.

• SyntaxError: The requested module 'lodash' does not provide an export named 'toPath' (or similar for CommonJS)

  cause The `toPath` function is an internal utility in modern Lodash (v4+) and is not directly exported from the main `lodash` or `lodash-es` packages.
  fix Rely on public Lodash functions like `_.get`, `_.set`, `_.has` which internally handle path parsing. If you specifically need the `toPath` logic and are using Lodash v3.x, use `require('lodash._topath')`.

Warnings

• breaking This `lodash._topath` package is based on Lodash v3.x. When migrating projects to Lodash v4.0.0 or later, be aware that many core Lodash APIs and internal behaviors changed. Relying on `lodash._topath` directly in a Lodash v4+ environment may lead to unexpected behavior or redundancy, as `toPath` is primarily an internal utility in modern Lodash.
  Fix: For new projects or migrations to Lodash v4+, prefer using the path resolution inherent in functions like `_.get`, `_.set`, or `_.has` from the main `lodash` or `lodash-es` packages. Avoid direct use of this internal v3.x package unless specifically required for legacy compatibility.
• gotcha The `lodash._topath` package (v3.x) is distributed as CommonJS. Attempting to use ES module `import` syntax (`import toPath from 'lodash._topath';`) will result in a runtime error.
  Fix: Always use CommonJS `require()` syntax: `const toPath = require('lodash._topath');`.
• gotcha `lodash._topath` is an internal utility, originally published separately for modularity in Lodash v3. Direct reliance on internal modules is generally discouraged as their API surface or existence may change without adhering to semantic versioning for external consumers. In modern Lodash (v4+), `toPath` is strictly an internal helper.
  Fix: If you need robust path parsing, consider using a dedicated path utility library or extracting the logic if you understand the implications. Otherwise, rely on the pathing provided by public Lodash methods like `_.get`, `_.set`, etc.
• gotcha While this specific package (`lodash._topath` v3.x) does not directly manipulate objects, users should be aware of a prototype pollution vulnerability (GHSA-f23m-r3pf-42rh) in `lodash` v4.18.0 concerning `_.unset` and `_.omit`. If paths generated by this (or any) `toPath` utility are subsequently used with vulnerable versions of `_.unset` or `_.omit` from the main `lodash` library, it could lead to security issues.
  Fix: Ensure any functions consuming paths (e.g., `_.unset`, `_.omit`) are from patched versions of `lodash` (v4.18.1 or higher) to mitigate prototype pollution risks. This particular `lodash._topath` package is not directly affected, but its output could be used in a vulnerable context.

Install

• npm install lodash._topath npm
• yarn add lodash._topath yarn
• pnpm add lodash._topath pnpm

Imports

• toPath
  wrong:

  import toPath from 'lodash._topath';

  correct:

  const toPath = require('lodash._topath');

  This `lodash._topath` package (v3.x) is CommonJS-only and provides the internal `toPath` utility from Lodash v3. Attempting to use ES module `import` syntax will result in a runtime error.
• toPath (via main Lodash)
  wrong:

  import { toPath } from 'lodash';

  correct:

  import { get } from 'lodash';

  In Lodash v4+, `toPath` is primarily an internal utility. It is not directly exported from the main `lodash` or `lodash-es` packages. Developers typically use public functions like `_.get`, `_.set`, or `_.has` which internally leverage path parsing logic similar to `toPath`.
• toPath (TypeScript types)

  type Path = string | Array<string | number | symbol>;

  This package does not export dedicated TypeScript types for `toPath`. The function expects a string or an array of path segments. You may need to declare a local type alias for clarity if using TypeScript with this specific (v3.x) package.

Quickstart

Demonstrates how to use `lodash._topath` to parse various string and array representations of object paths into an array of segments, showcasing its handling of dot and bracket notation for robust property access.

const toPath = require('lodash._topath');

// Example 1: Basic string path
const path1 = 'user.address.street';
console.log(`Path "${path1}" parsed:`, toPath(path1));
// Expected: [ 'user', 'address', 'street' ]

// Example 2: Path with array index
const path2 = 'data.items[0].name';
console.log(`Path "${path2}" parsed:`, toPath(path2));
// Expected: [ 'data', 'items', '0', 'name' ]

// Example 3: Path with mixed notation and special characters
const path3 = 'config["api-keys"][1].secret';
console.log(`Path "${path3}" parsed:`, toPath(path3));
// Expected: [ 'config', 'api-keys', '1', 'secret' ]

// Example 4: Already an array (should return itself)
const path4 = ['config', 'version'];
console.log(`Path ${JSON.stringify(path4)} parsed:`, toPath(path4));
// Expected: [ 'config', 'version' ]

// Example 5: Non-string, non-array input (should convert to string then path)
const path5 = Symbol('id');
console.log(`Path ${String(path5)} parsed:`, toPath(path5));
// Expected: [ 'Symbol(id)' ]