Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[RFC]: rename primitive array `assert` packages

Aperta
  • Qualcosa non va?
#14,283 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
javascript
Ambito
developer-experience, tooling

Direzione di ricerca

Inizia esaminando i nomi elencati dei pacchetti primitive-array e cercandone gli utilizzi nel progetto. Considera la convenzione proposta -of-, il lavoro di migrazione, le implicazioni per JSDoc e la deprecazione su npm e GitHub. Il lavoro è concluso quando l’approccio alla denominazione è concordato e l’ambito della migrazione risultante è definito.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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:.
Lingua principale
JavaScript
Stelle
6k
Fork
1.3k
Merge medio
1g 3h
PR unite (30g)
585

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di stdlib-js/stdlib

Tutte le issue di stdlib-js/stdlib

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.