jackwright.social
Web developer. Osu! enjoyer.
github.com/jack3898
416 posts
130 followers
124 following
Regular Contributor
Active Commenter
comment in response to
post
That looks AMAZING nice work!! 💯
comment in response to
post
I found this really useful contribution which helped. But I am still not satisfied. :(
comment in response to
post
Is there a common pattern anyone uses for this scenario? The problems and edge cases are plentiful and above is one of many issues I have with it.
comment in response to
post
This leads to nasty things like this:
const update = {
...(typeof telematics === "boolean" ? { telematics } : {}),
}
It just looks ugly and unweildy and it's very buggy as these spreads end up being quite specific and tailor made to the field.
comment in response to
post
This becomes a problem when I want to pass this data through to the database; I want the data to be required in the db, but key optional in GraphQL to selectively update what I need.
But... GraphQL's schema says optional types may be null, but I only want non-nullable & key optional.
comment in response to
post
I am creating a mutation to update data. This update has an input type that has fields that are 100% optional.
In the backend, these GraphQL input fields can either by a type of data, null or not in the record at all. Or, if required, must be provided and not null.
comment in response to
post
Vitest is already using it in their latest update. 👀
comment in response to
post
Yeah that's the perfect use case for it!!
comment in response to
post
Wooo esm only!!
comment in response to
post
Never tried connectors. 👀 Looks very interesting
comment in response to
post
Might have to start referring to you guys as AiCrunch 😂
comment in response to
post
It never ends. ðŸ˜
comment in response to
post
Love that 🤣
comment in response to
post
Got anything wrong? Lemme know!
comment in response to
post
One other important thing, don't delete your lockfile!! Again, this is a record of the resolved versions since the last update. Deleting this gives npm permission to change a load of versions (even with dependency pinning!) and resolve a new dependency tree fresh. That will be sure to break things.
comment in response to
post
To be honest, I don't really use `npm update` all that much, I like to randomly pick some packages and update them manually. Or update the ones with CVE's attached to them.
In this scenario, it's actually not that useful to be pedantic about dependency ranges because I still have update control.
comment in response to
post
And as a package maintainer this is even more important. Tighten your dependencies enough to improve stability for users of your package, but not too much where they might end up with duplicate dependencies (also don't overthink it). Your users won't download your lockfile! npm forbids it.
comment in response to
post
Instead of pinning to exact versions, refine your package.json dependency ranges! This means you can do an `npm update`, and rest easy knowing it will update in the safest possible way as outlined by your specified dependency ranges.
comment in response to
post
Only when you use `npm update`, does the lockfile change. `npm update` will update a package or list of packages AUTOMATICALLY, with the latest version of a dependency it can get away with as per your package.json.
comment in response to
post
This is why lockfiles exist; they keep a record of the tree of package versions that were resolved on install. If the corresponding lockfile package version satisfies the dependency range in the package.json it does not touch it and will download the recorded version per the lockfile.
comment in response to
post
This is the first important thing:
Pinning your package.json versions only pins the top-level dependencies. You are completely at the mercy of package maintainers version choices when npm starts going deeper and you have very little control over these versions unless you define explicit overrides.
comment in response to
post
While resolving the dependencies it crawls through to the dependency's package.json, reads its version ranges, then resolves a list of the latest sub-dependencies it can get away with as per the package's specified ranges.
comment in response to
post
Let's start with what happens when you `npm install` for the first time.
npm will read your package.json, and using the dependency ranges you specify, will resolve the list of the latest dependencies it can get away with as per your specified ranges ("^", "^" and anything else).
comment in response to
post
Before I get into the why's, I need to start with the what's.
The "~" means any patch. The "^" means any minor & patch. There is additional syntax to fine-tune ranges even more, but many projects don't bother getting precise which is ok assuming it's like that within reason.
comment in response to
post
I would argue, that instead of blanket removing these symbols for "stability" which is actually making your life harder (but not by much) you should fine-tune these symbols to make your life updating packages easier with `npm update`.
Let me explain.
comment in response to
post
Yeah especially with the thought of it being connecte to the in-
I'll stop.
comment in response to
post
I personally prefer Dominick's, as there's less scope for implementation logic to go wrong and thinking declaratively (in React) leads to easier to reason with code.
Definitely close for me though, I'm happy with either!
comment in response to
post
Can't go wrong with a good ol' bri'ish quencher. ☕
comment in response to
post
In most cases async functions are OK, but in something like GraphQL, where resolvers are a thing, Promises become quite an expensive thing to compute per request.