Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[RFC]: rename primitive array `assert` packages

Abierto
  • ¿Algo no está bien?
#14,283 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
javascript
Área
developer-experience, tooling

Línea de trabajo

Empieza revisando los nombres de los paquetes de primitive-array enumerados y buscando sus usos en el proyecto. Considera la convención -of-, el trabajo de migración, las implicaciones para JSDoc y la deprecación en npm y GitHub. Se considerará terminado cuando se haya acordado el enfoque de nomenclatura y se haya definido el alcance de la migración resultante.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Maintainers Needs Discussion release: Major RFC
Description

This RFC proposes renaming the following packages:

  • is-array-array => is-array-of-arrays

    • alias: isArrayArray => isArrayOfArrays

  • is-boolean-array => is-array-of-booleans

    • alias: isBooleanArray => isArrayOfBooleans

  • is-date-object-array => is-array-of-date-objects

    • alias: isDataObjectArray => isArrayOfDateObjects

  • is-function-array => is-array-of-functions

    • alias: isFunctionArray => isArrayOfFunctions

  • is-integer-array => is-array-of-integers

    • alias: isIntegerArray => isArrayOfIntegers

  • is-nan-array => is-array-of-nans

    • alias: isNaNArray => isArrayOfNaNs

  • is-negative-integer-array => is-array-of-negative-integers

    • alias: isNegativeIntegerArray => isArrayOfNegativeIntegers

  • is-negative-number-array => is-array-of-negative-numbers

    • alias: isNegativeNumberArray => isArrayOfNegativeNumbers

  • is-nonnegative-integer-array => is-array-of-nonnegative-integers

    • alias: isNonNegativeIntegerArray => isArrayOfNonNegativeIntegers

  • is-nonnegative-number-array => is-array-of-nonnegative-numbers

    • alias: isNonNegativeNumberArray => isArrayOfNonNegativeNumbers

  • is-nonpositive-integer-array => is-array-of-nonpositive-integers

    • alias: isNonPositiveIntegerArray => isArrayOfNonPositiveIntegers

  • is-nonpositive-number-array => is-array-of-nonpositive-numbers

    • alias: isNonPositiveNumberArray => isArrayOfNonPositiveNumbers

  • is-null-array => is-array-of-nulls

    • alias: isNullArray => isArrayOfNulls

  • is-object-array => is-array-of-objects

    • alias: isObjectArray => isArrayOfObjects

  • is-plain-object-array => is-array-of-plain-objects

    • alias: isPlainObjectArray => isArrayOfPlainObjects

  • is-positive-integer-array => is-array-of-positive-integers

    • alias: isPositiveIntegerArray => isArrayOfPositiveIntegers

  • is-positive-number-array => is-array-of-positive-numbers

    • alias: isPositiveNumberArray => isArrayOfPositiveNumbers

  • is-primitive-array => is-array-of-primitives

    • alias: isPrimitiveArray => isArrayOfPrimitives

  • is-probability-array => is-array-of-probabilities

    • alias: isProbabilityArray => isArrayOfProbabilities

  • is-safe-integer-array => is-array-of-safe-integers

    • alias: isSafeIntegerArray => isArrayOfSafeIntegers

  • is-string-array => is-array-of-strings

    • alias: isStringArray => isArrayOfStrings

  • is-symbol-array => is-array-of-symbols

    • alias: isSymbolArray => isArrayOfSymbols
Rationale

As the project has grown and started accumulating custom array types (e.g., BooleanArray, Complex128Array, Int64Array, etc), older naming conventions are beginning to conflict with continued project evolution.

The most immediate example is is-booleanarray and is-boolean-array. Which is the assertion package for BooleanArray and which is for an array of booleans (e.g., [ true, false, true ])? It is not obvious which is which and can be a point of confusion.

This RFC proposes migrating existing packages which refer explicitly to the contents of a collection and not to a particular instance type to a new naming convention which more explicitly indicates what the package is intended to test for and should avoid conflicts with any future array types (e.g., StringArray, ObjectArray, etc).

Notes

Packages which are not included in the proposed migration:

  • is-between-array
  • is-falsy-array
  • is-finite-array
  • is-truthy-array
  • is-unity-probability-array

These packages were considered to be (a) highly unlikely to conflict with future specialized array constructors and (b) not have good readability with the proposed naming convention (e.g., isArrayOfBetween).

Related Issues

N/A

Questions

  1. The proposed changes will create quite a bit of churn throughout the project as many of these packages are heavily used. The question is then whether the churn is worth it. In my opinion, it is, but others may have different opinions.

  2. Is there a better naming convention than the *-of-* proposal above?

  3. JSDoc conventions are intentionally left out (e.g., @param {NonNegativeIntegerArray}). IMO, these also need to be migrated in order to avoid confusion with class instances, but I think this is something which can be addressed in a separate RFC, as it is not clear what the naming convention should be (e.g., Array<integer>, Array<nonnegative_integer>, something else?).

Other

cc @Planeshifter as we previously discussed the confusion between is-boolean-array and is-booleanarray. This is my attempt to resolve that confusion.

Should this RFC be accepted and completed, we'll want to deprecate the existing packages and have them point to the new packages on both npm and GitHub.

Checklist
  • I have read and understood the Code of Conduct.
  • Searched for existing issues and pull requests.
  • The issue name begins with RFC:.
Lenguaje dominante
JavaScript
Estrellas
6k
Forks
1.3k
Merge medio
1 d 9 h
PR fusionados (30 d)
607

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de stdlib-js/stdlib

Todos los issues de stdlib-js/stdlib

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.