Dev Feed

PullRequestReviewEvent

Got you. Misread from me. That's what you get for reviewing on a phone!

So then, is there anyone who is against the idea of merging a PR to update the README? Is anyone still around who has the rights to do that? cc @blakeembrey @cspotcode It also feels like we're in the territory of marking the npm package itself as deprecated...? https://docs.npmjs.com/deprecating-and-undeprecating-packages-or-package-versions At least these would be fairly trivial changes, and would flag to developers to use something else.

Just came across this as a requirement in one of our features and we've had to use raw. +1 on this. Could potentially look at myself at some point.

Yes, happy to take some time to raise the PR. Will try and get something proposed this week.

Got you. Good to hear.

Hi, Is this package effectively now abandonware? I note @evanshortiss comment here indicates that https://github.com/evanshortiss/env-var/issues/156#issuecomment-2371089961 With 500k downloads a week this seems a real shame. Are people using more widely adopted alternatives?

**Is your feature request related to a problem? Please describe.** Surprised to not find a Date / DateISOString validator in this package. Has it been considered? Feels like it could be quite simple to implement. **Describe the solution you'd like** - asDateISOString() method. - Validates it. If it's not, fails fast and loud. **Describe alternatives you've considered** - Custom validation after env-var usage, but that needs to be hand-cranked.

PullRequestReviewEvent

Do we need to replace nanoid here?

Looks like a good change to me

> Seems like a general AWS SDK issue in Lambda only. > > We get this for SecretsManager SDK. > > AI tooling recommends moving the instantiation inside the execution context, but that hasn't worked, which is very weird - that signals some underlying cache behaviour that we can't control outside of the execution context? > > None of our latency logs point to any kind of delay even close to 5 minutes: I'm working on high throughput, fast acting lambdas by design ~10-100ms. > > This is contributing about ~4,000 errors a week across our ecosystem out the moment. A real noise issue. We found the issue actually: it was a Datadog agent / dependency in our lambdas. We updated the setup and the errors disappeared. We're not getting these errors now with a standard SDK V3 setup instantiated outside of execution context.

Confirmed the above works as a direct devDependency in a repo using ESLint 8.56.0

Perhaps superceded by https://github.com/antfu/eslint-plugin-format. Not tested myself yet, but supports `dprint`

Just came across this too. Unfortunately chimes with other ESLint upgrades I've had to do in the past where lots of things seem to break.

On decrypting cookies set by one particular site (Goodreads.com), I got the following error: > RangeError: out of range index > at RangeError (native) > at decrypt (node_modules/chrome-cookies-secure/index.js:59:8) > at Statement.db.each.host (node_modules/chrome-cookies-secure/index.js:268:21) The offending line 59 is `final.copy(decoded, decoded.length - 1);`. Changing it to `final.copy(decoded, decoded.length ? decoded.length - 1 : 0);` (no longer assuming that the target buffer contains data) fixed the issue for me, though I don't know if that's the best solution.

Closing given inactivity, no other reports, and works on latest release.