should.js Utility Functions

Common errors

• TypeError: (0 , should_util__WEBPACK_IMPORTED_MODULE_0__.isString) is not a function

  cause Attempting to use ES module named imports in a bundler that struggles with CJS interop, or directly in an environment that expects explicit ES exports. This usually means the bundler didn't correctly resolve `module.exports` to named imports.
  fix Try importing the entire module as a default import and then accessing properties: `import util from 'should-util'; console.log(util.isString('test'))`. Alternatively, configure your bundler (e.g., Webpack, Rollup) to better handle CommonJS modules, or ensure `module.exports` is correctly identified as the source of named exports.

• Error [ERR_REQUIRE_ESM]: require() of ES Module ... Not supported by CommonJS 'require'.

  cause This error would typically occur if `should-util` were an ESM package being `require()`d. However, `should-util` is CJS. If you encounter this, it likely means another dependency or the consuming project is configured as ESM-only, and the tooling is failing to correctly load `should-util` as CJS.
  fix Ensure your project's module resolution (`tsconfig.json#moduleResolution`, `package.json#type`) is compatible with CommonJS modules. If you are in a pure ESM environment, you may need to use a dynamic `import()` or find an ESM-native alternative for the desired functionality.

Warnings

• gotcha The `should-util` package is primarily a CommonJS module. While modern bundlers can often convert `import` statements, it does not explicitly define ES module entry points using the `package.json#exports` field. This may lead to compatibility issues in pure ESM environments or older tooling.
  Fix: For direct CommonJS usage, use `const { utility } = require('should-util');`. For ES module usage in environments without strong CJS interop, ensure your build tool handles CJS packages or consider alternative, actively maintained utility libraries.
• gotcha This package is in maintenance mode with no active development. The last commit was 7 years ago, and there have been no new releases in a decade. While stable, it lacks modern features, TypeScript definitions, or updates for newer JavaScript language constructs or environments.
  Fix: Be aware that new features or bug fixes are unlikely. If using TypeScript, you will need to provide your own declaration files (`.d.ts`) or rely on implicit `any` typing. Consider the implications for long-term project viability.
• gotcha Many of the basic type-checking utilities (e.g., `isString`, `isArray`) provided by `should-util` have native JavaScript equivalents (e.g., `typeof ''`, `Array.isArray()`) or are readily available in more modern, actively maintained utility libraries (e.g., Lodash, Ramda). Over-reliance on this specific package for basic tasks might introduce an unnecessary, unmaintained dependency.
  Fix: Evaluate if a specific utility function is truly needed from `should-util` or if a native JavaScript method or a function from a more actively developed library would suffice.

Install

• npm install should-util npm
• yarn add should-util yarn
• pnpm add should-util pnpm

Imports

• isString
  wrong:

  const { isString } = require('should-util')

  correct:

  import { isString } from 'should-util'

  While CommonJS `require` is the primary usage, modern bundlers can often convert this to ESM named imports. The package itself is a CJS module without `exports` field in package.json.
• deepEqual
  wrong:

  import deepEqual from 'should-util/lib/deepEqual'

  correct:

  import { deepEqual } from 'should-util'

  The `deepEqual` function is a named export from the main entry point, not a default export or a direct submodule import.
• isArray
  wrong:

  const isArray = require('should-util').isArray

  correct:

  import { isArray } from 'should-util'

  Destructuring is recommended for specific utility functions. Direct property access (e.g., `require('pkg').prop`) is functional but less idiomatic for multiple imports in modern JavaScript.

Quickstart

Demonstrates importing and using `isString`, `isArray`, and `deepEqual` for type checking and object comparison, key utilities from the package.

import { isString, isArray, deepEqual } from 'should-util';

// Example 1: Type checking a string
const myString = 'Hello, world!';
console.log(`'${myString}' is a string: ${isString(myString)}`);
// Expected: 'Hello, world!' is a string: true

// Example 2: Type checking an array
const myArray = [1, 2, 3];
console.log(`${JSON.stringify(myArray)} is an array: ${isArray(myArray)}`);
// Expected: [1,2,3] is an array: true

// Example 3: Deep equality comparison
const objA = { a: 1, b: { c: 2 } };
const objB = { a: 1, b: { c: 2 } };
const objC = { a: 1, b: { c: 3 } };

console.log(`objA deepEqual objB: ${deepEqual(objA, objB)}`);
// Expected: objA deepEqual objB: true
console.log(`objA deepEqual objC: ${deepEqual(objA, objC)}`);
// Expected: objA deepEqual objC: false

// Example 4: Demonstrating other exports
import util from 'should-util'; // For older bundlers or direct CommonJS require
console.log(`Is null undefined? ${util.isUndefined(null)}`);
console.log(`Is undefined undefined? ${util.isUndefined(undefined)}`);