Typical Type Checking Utilities

Common errors

• TypeError: (0 , typical__WEBPACK_IMPORTED_MODULE_0__.isNumber) is not a function

  cause Attempting to named import individual functions directly from 'typical' in an ESM context, while the package exports them as properties of a default object.
  fix Correct the import to `import t from 'typical'` and access functions as `t.isNumber` or destructure like `const { isNumber } = t;`.

• TypeError: Cannot read properties of undefined (reading 'isNumber')

  cause The default export `t` was not correctly imported or `require()`d, leading to `t` being `undefined` or an empty object, and thus `t.isNumber` doesn't exist.
  fix Ensure `import t from 'typical'` (ESM) or `const t = require('typical')` (CJS) is at the top of your file and executed correctly. Check for typos in the import path or variable name.

• ERR_REQUIRE_ESM

  cause Attempting to `require()` the `typical` package in a CommonJS module when the package is designed as ESM-only or explicitly specifies `"type": "module"` without a CJS entry point for `require`.
  fix For CommonJS projects, either configure your bundler/environment to transpile ESM to CJS, or explicitly use dynamic `import('typical').then(m => m.default)` if it's ESM-only. The best fix is to migrate to ESM (`"type": "module"` in `package.json`) and use `import t from 'typical'`.

Warnings

• breaking Older Node.js environments (pre-12.17) might encounter issues with module resolution or performance. While the package specifies `>=12.17`, consistent ESM/CJS interop can be complex in mixed environments. Users should ensure their Node.js version meets or exceeds the minimum requirement for full compatibility.
  Fix: Upgrade Node.js to version 12.17.0 or higher. For bundlers, ensure proper configuration for ESM resolution.
• gotcha The `isNumber` function in `typical` returns `false` for `NaN`, which differs from JavaScript's built-in `typeof NaN === 'number'`. If you need to include `NaN` as a number, or specifically exclude `Infinity`, use `isFiniteNumber` or `Number.isFinite` directly, or combine `t.isNumber` with `Number.isNaN` for custom logic.
  Fix: Be aware of `isNumber`'s specific behavior regarding `NaN`. Use `t.isFiniteNumber(value)` for strictly finite numbers, or `(t.isNumber(value) || Number.isNaN(value))` if `NaN` should be considered a number for your specific use case.
• gotcha The `isPlainObject` method specifically checks for objects created by the `Object` constructor or object literals. It returns `false` for instances of custom classes (e.g., `new MyClass()`), Arrays, or Dates. Use `isObject` if you simply need to check if a value is any object (not `null`).
  Fix: Distinguish between `t.isPlainObject(value)` for pure object literals and `t.isObject(value)` for any non-null object type. Understand the specific definition of 'plain object' as implemented by the library.
• gotcha When using `require()` in CommonJS modules, if the `package.json` of `typical` is configured for ESM with a default export, you might implicitly need to access the `.default` property (e.g., `require('typical').default`). However, modern Node.js often handles interop automatically, so this is a 'depends on environment' situation.
  Fix: Prefer `import t from 'typical'` for ESM projects. For CJS, try `const t = require('typical')`. If `t` appears empty or its methods are undefined, try `const t = require('typical').default` as a fallback or ensure your environment supports ESM/CJS interop.

Install

• npm install typical npm
• yarn add typical yarn
• pnpm add typical pnpm

Imports

• t
  wrong:

  import { isNumber, isPlainObject } from 'typical'

  correct:

  import t from 'typical'

  The library primarily exports a single default object `t` containing all type-checking functions. Direct named imports for individual functions are generally incorrect unless explicitly configured via `package.json` exports mapping in newer versions (not shown).
• t
  wrong:

  const t = require('typical').default

  correct:

  const t = require('typical')

  While `typical` is primarily ESM-first, it often provides CommonJS compatibility. Direct `require('typical')` usually works for the default export. Accessing `.default` might be necessary in some transpiled or specific interop scenarios, but `require('typical')` is the typical CJS pattern.
• isNumber
  wrong:

  import { isNumber } from 'typical'

  correct:

  import t from 'typical'; const isNum = t.isNumber;

  Individual type-checking functions like `isNumber` are properties of the default-exported `t` object, not direct named exports. Destructuring from `t` (e.g., `const { isNumber } = t;`) or accessing them via `t.isNumber` is the correct approach.

Quickstart

Demonstrates importing the default `t` object and using various type-checking functions like `isNumber`, `isFiniteNumber`, `isPlainObject`, `isObject`, `isDefined`, `isUndefined`, `isString`, and `isArrayLike` on different data types.

import t from 'typical';

const data = [
  10, NaN, Infinity, 'hello', null, undefined,
  { a: 1 }, new Date(), [1, 2, 3]
];

console.log('--- Checking Numbers ---');
console.log('Is 10 a number?', t.isNumber(10)); // true
console.log('Is NaN a number?', t.isNumber(NaN)); // false (differentiator from typeof)
console.log('Is Infinity a finite number?', t.isFiniteNumber(Infinity)); // false

console.log('\n--- Checking Objects ---');
console.log('Is { a: 1 } a plain object?', t.isPlainObject({ a: 1 })); // true
console.log('Is new Date() a plain object?', t.isPlainObject(new Date())); // false
console.log('Is new Date() an object?', t.isObject(new Date())); // true

console.log('\n--- General Checks ---');
console.log('All defined values in data:', data.filter(t.isDefined));
console.log('Any undefined values in data:', data.some(t.isUndefined));
console.log('Are all strings?', ['a', 'b', 'c'].every(t.isString)); // true
console.log('Is an array-like object?', t.isArrayLike({ length: 3, 0: 'a' })); // true