The simplest reason might be that it's not the default so people use npm out of habit.
Personally, I use volta and switch between node versions in different projects, so I prefer to just use npm.
94 karma · joined March 24, 2015
Personally, I use volta and switch between node versions in different projects, so I prefer to just use npm.
Enabling `ignore-scripts=true` protects you from almost all of the recent compromises `min-release-age=3` protects you from the rest. But you still typically need trusted dependency builds, which this script solves.
I hope that npm enables this by default in the future.
Pinned package versions in npm solves this.
If you want to use the latest dependencies then yes there is ongoing management required. There are tools to help with this.
Let me know your use case as I am still learning where it can provide the most value and how I should go about charging for it.
I welcome feedback on pricing/self-hosted.
1. I would replace the chairlift sequence in place of a shortened animation or just make it teleport.
2. Keyboard shortcuts.
3. Where's the monster? ;)
import * as v from 'valibot';
const OptionalKeySchema = v.object({ key: v.optional(v.string()) });
type t1 = v.InferInput<typeof OptionalKeySchema>; // { key?: string }
const UndefinedKeySchema = v.object({ key: v.undefinedable(v.string()) });
type t2 = v.InferInput<typeof UndefinedKeySchema>; // { key: undefined }I have some feedback on your homepage & messaging.
Initially scrolling the home page I thought it was a tool for viewing customer bug sessions, similar to TrackJS or Sentry.
Reading this post it became clear this is for product managers and/or team members to file bugs. The line "Built for everyone" on the home page threw me off.
I think if you make the distinction that this is an internal tool for teams vs. an external tool for tracking customer issues it might help make this messaging clearer.
I'm not sure of your plans (perhaps you also intend for external users to use it) this was just my first pass impression.
I think this is a great tool. The structured format combined with the information provided by the extension are what make it valuable to me. The last minute feature is also nice as re-creating bugs can be a PITA.
As a dev, I would ideally also want to be able to view stack traces with source maps, but having a consistent structured format combined with the extension data is enough of a value prop to start using it.
Now that I’ve thought about it what I’m actually trying to ask is…
What would it take to drop flight prices 50%?
Automated flights, a change in fuel technology, 0 marketing spend, reduced maintenance?
More specifically, what is the bare bones cost to transport a human from point a to b, safely, in the same or less time it takes a flight.
What is the long term plan here? Will there still be duo pilots in 2040? 2060?
Surely long term it will be automated with remote supervision/override and a cabin crew who have basic training to emergency land.
Do the testing on mail delivery, get it good enough, introduce it into domestic with pilots still present, slowly phase out pilots to be remote.
I would fly domestic automated flights if the automation was proven as safe, the above conditions were met, and the price was 40-50% cheaper.
I don’t see why a company hasn’t gone all in on this yet, but would love to hear why it’s a dumb idea/not feasible.
* Edit: based off this link it seems that staffing is only 12% of costs which would not address my criteria of significantly cheaper flights. https://aviation.stackexchange.com/questions/33770/how-much-...
Steps:
1. Settings > Screen time > Use screen time pass code > Enter a different passcode to your main one that you will remember
2. Settings > Screen time > Content & Privacy Restrictions > Scroll down to Account changes > Don’t allow
This prevents account changes from the device, unless you have the second passcode.
This would not prevent a thief who was aware of this (they could attempt to disable screen time then request the second passcode), but it would prevent a pickpocket who happens to see your passcode being entered from changing your iCloud account details.
I am not aware of such solutions but would be interested to learn more if there are.
Not suggesting macros, rather an alternative way to define types. A function that accepts and returns types. Seeing as typescript has a JavaScript interpreter I thought it might be feasible but I'm just spitballing it.
> Eh. It's not like Java has a "type debugger." Why is this needed? Why are your types so complex? Weird ask.
I don't buy this argument. Writing any type of complex types with recursion, arrays or ternaries sucks and it will take more than "this is how Java does it" to convince me otherwise. I like to debug with a debugger, not my head.
Take a look at the examples in the article to see some complex types and read some tweets from library authors complaining on twitter. I can find some examples if you're interested.
> We have a pretty clear typescript spec
I hadn't actually seen this and it looks interesting but seems pretty out of date, Typescript 1.8?
Surely that's not the only alternative.
Here's a few off the top of my head:
- Being able to write complex types in a syntax that more closely resembles JavaScript. Using Array length for counting or nested ternaries for if logic gets old fast.
- Being able to debug types, not console output, a real debugger. See: https://twitter.com/MarcJSchmidt/status/1539787500788613120
- More comprehensive documentation on writing advanced types
- A typescript specification
Here's a monorepo example, it's using cloudflare workers instead of node. But you could set up a vite-node server using concurrently or create a vite plugin.
> Consider extracting this to a separate function to make this more re-usable.
This gives the developer the option to disregard the comment. Essentially I am trusting that they will consider it. It shows that I trust their judgment instead of ordering them.
For stuff that is more important but not critical I prefix with "I'd recommend".
I'd recommend doing [current approach] [migration statement] [your suggestion]. It will [benefit].
> I'd recommend testing UI components in a similar way that a user would interact with it. It will make your tests more resilient and prevent other developers from breaking your code.
> I'd recommend moving this logic into it's own function, it will allow this code to be used by future developers and allow you to test it easier.
This both declares the recommendation and explains why it was recommended.
For stuff that is critical, I might just write it more directly:
> We need to extract this into it's own function so it doesn't lead to/cause X.
I am struggling to understand this one.
Is he saying that you should remove parts on a routine basis, like a "remove parts/processes" meeting every month and then re-adding them back in once you find they're needed.
Or is he saying when you get a list of requirements, remove parts/processes related to those requirements and then re-add them once you find they're needed?
Or is it something else entirely?