fix(types): optional properties on RedisOptions allow explicit undefined#2066
Conversation
|
Hi, I’m Jit, a friendly security platform designed to help developers build secure applications from day zero with an MVS (Minimal viable security) mindset. In case there are security findings, they will be communicated to you as a comment inside the PR. Hope you’ll enjoy using Jit. Questions? Comments? Want to learn more? Get in touch with us. |
❌ Security scan failedSecurity scan failed: Branch fix/username-and-password-have-explicit-undefined-types does not exist in the remote repository 💡 Need to bypass this check? Comment |
|
@sera bypass |
|
@avocadojesus Appreciate you putting this together. When you get a chance, could you apply the same change to keep things consistent in: |
94d04eb to
e2ddbb7
Compare
absolutely, done! Thanks for maintaining the project and giving me the time of day, I appreciate you 🙏 . Curious, I noticed prettier kicking in, so i went ahead and ran the |
…erOptions
when exactOptionalPropertyTypes is true in the consuming application's tsconfig, you cannot send in an explicit undefined for these fields, causing the developer to jump through extra hoops needlessly to get i.e. the username and password provided to the options in a type-safe manner. This fix corrects this by explicitly specifying undefined as an allowed type on the username and password properties within RedisOptions, SentinelConnectionOptions, and ClusterOptions.
```ts
new Redis({
...
password: process.env.REDIS_PASSWORD,
})
```
e2ddbb7 to
505bce6
Compare
when
exactOptionalPropertyTypesis true in the consuming application's tsconfig, you cannot send in an explicit undefined for these fields, causing the developer to jump through extra hoops needlessly to get i.e. the username and password provided to the options in a type-safe manner. This fix corrects this by explicitly specifying undefined as an allowed type on the username and password properties within RedisOptions.