https://underscorejs.org/#chunk

The types for _.compact seem to work fine. But this is a util that I use frequently, so it would be nice to have a non-underscore version of it.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

• chore: update dependency typescript to v5
• chore: lock file maintenance
• 🔐 Create all rate-limited PRs at once 🔐

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore: update @silvermine/typescript-config digest to ea8b792
• chore: update dependency @silvermine/standardization to v2.2.3
• chore: update dependency chai to v4.5.0 (chai, @types/chai)
• chore: update dependency grunt-cli to v1.5.0
• chore: update dependency @types/node to v20
• chore: update dependency @types/sinon to v17
• chore: update dependency mocha to v10 (mocha, @types/mocha)
• chore: update dependency nyc to v17
• chore: update dependency sinon to v18
• chore: update dependency ts-node to v10
• Click on this checkbox to rebase all open PRs at once

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• chore: update dependency @types/node to v12.20.55
• chore: update dependency chai to v5
• chore: update dependency eslint to v9

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

See: https://www.builder.io/blog/utility-types#:~:text=But%2C%20now%20that%20we%20are%20aware%20of%20Readonly%2C%20we%20can%20combine%20that%20with%20its%20sibling%20ArrayReadonly%2C%20and%20a%20little%20bit%20of%20magic%2C%20and%20make%20our%20own%20DeepReadonly%20type%20like%20so%3A

We would like a Promise utility that acts a little like allSettled in that it allows all Promises in a given array of Promises to resolve or reject, but the end result is a rejected Promise if any Promise in the array is rejected.

This simplest implementation of this would be:

return Promise.allSettled(contentDocPromises).then((results) => {
   for (let result of results) {
      if (result.status !== 'fulfilled') {
         return Promise.reject(result.reason);
      }
   }
});

But that implementation loses the values that resolved Promises returned and only surfaces a single reason for rejection when there could be multiple.

Perhaps the function could resolve with the array of resolved values if all Promises resolve, and reject with an array of rejection reasons for any rejected Promises (or just reject with the array of results so that resolved values are not lost).

Currently, isEmpty just returns a boolean. It would be much more useful if it were a type-guard that asserted that its parameter was one of the "empty" object types its checking for.

Scenario

We often need to filter undefined or null values from arrays. The Array#filter method is typed so that if the callback function passed to the filter method is a type guard, filter's return type is the same as what the type guard asserts:

const arr: number | undefined = [ 1, undefined, 2 ];

const onlyNumbers = arr.filter((n): n is number {
   return !isUndefined(n);
});
// onlyNumbers is automatically typed as `number[]`

Instead of writing these type guard functions ad-hoc, it would be convenient if we had a function that asserts that a variable is NonNullable<T>. Then, we could just:

const onlyNumbers = arr.filter(isNotUndefinedOrNull);

Naming

Possible names for the type guard function: isNotUndefinedOrNull, isNonNullable

isEmpty doesn't currently work for Sets.

For example:

> let a = new Set([ 1, 2, 3, 4, 5 ]);
> isEmpty(a)
true

I had to hunt around to find the issue in my code and it came back to this. Seems like we have been using sets a bit more recently, so it would be nice to support it in the toolbox.

The types for _.range seem fine. But this is a util that I use frequently, so it would be nice to have a non-underscore version of it.

Example:

> _.range(5)
[ 0, 1, 2, 3, 4 ]

The typing isn't bad on _.uniq. However, for projects without underscore, this is handy to have.

https://underscorejs.org/#uniq

Toolbox contains type guards for generic types such as isNumber. However, for booleans we have to resort to something like:

interface Animal {
   isAdoptable?: boolean;
}

const stuffedTiger: Animal = {},
      russianBlue: Animal = { isAdoptable: true };

// Type 'undefined' is not assignable to type 'boolean'. (2322)
const isAdoptable: boolean = stuffedTiger.isAdoptable;

if (stuffedTiger.isAdoptable === false || stuffedTiger.isAdoptable === true) {
   // works
   const isAdoptable: boolean = stuffedTiger.isAdoptable;
}

if (stuffedTiger.isAdoptable !== undefined) {
   // works
   const isAdoptable: boolean = stuffedTiger.isAdoptable;
}

TS Playground: https://www.typescriptlang.org/play?#code/JYOwLgpgTgZghgYwgAgIImAWzgG2QbwChkTgBnVAEwHsAHMOAIxwgH4AuZR66luEANyEAvoUIJqIMmGTSArjBgRKAFWABzaJ3RZcyALwFhAGmIlzUOWTLB+AIRxyI2jNjyH8yclToNmz5DBLFGEhQgB6cOQVAE9aFAByORBKCBhQZQSvMmQQahk4aw0QJhZA6kC4xO5eCH4EgDpkAAoAJgBmVtaASnFJaWyfelKAmr4QA1kwBSVVDWgG7xph-zDgGBb5RWU1TShFimW-Mv1T5HgcMhQAH2upmZ35-aXfEYMzoKdugjNkSOQAO7UKAAazIvwkUhkLxWLE4YzqE0MW1muwWMOOECEokI602022cz2ByGmOQAEIzslUukQMpvkRzP8gaDweZIQMMSN4TxxpMUY9iVzViIgA

We should add an isBoolean type guard.

Example:

interface TestType {
   readonly prop: string;
   readonly anotherProp: number;
   readonly optionalProp?: string;
}

// results in: "anotherProp" | undefined
PropsWithType<TestType, number>

We maintain the Undertemplate project for our minor templating needs. It uses Lodash and makes the templating function CSP-compliant, removing the "eval"-code execution parts of the templating function.

We continue to have a need for Undertemplate, but it would be nice to drop the Lodash dependency and add TypeScript types. We could do so in the Undertemplate project itself, but now that we have the toolbox project that's installed in so many places, it's most convenient to maintain it here. Additionally, the Undertemplate implementation makes use of toolbox functions, so it's helpful to co-locate them.