This article appears to be talking about lockfiles for libraries - and I agree, for libraries you shouldn't be locking exact versions because it will inevitably pay havoc with other dependencies.
Or maybe I'm missing something about the JavaScript ecosystem here? I mainly understand Python.
I didn't like the use of the word "pro-abortion". I generally address them as pro-life even though I don't like that it indirectly indicates that the other side would be "anti-life" but I agree that it's not productive to get into a flame war on terminology.
I see two comments here on this subject, complaining about the churn of dealing with security advisories. Sure, it's churn.
... but isn't this problem dwarfed by the implications of having used a compromised package? Presumably, if the project you work on has a compromised dependency, it means you've ran it on your development machine. Presumably, you might have a couple of secrets (private keys, AWS credentials and other whatnots) lying around, which might have leaked to a malicious actor.
Wouldn't you need to review all the development, staging and production machines for all your projects and rotate secrets everywhere?
Wouldn't it be, by far, the biggest churn involved, so much that mentioning "npm audit" difficulties not worth mentioning at all, because of the ridiculous comparison in effort magnitude?
The vast majority of "compromised packages" are just dev dependencies that have a slow regexp.
I think you are confusing megabytes a second and megabit. Gigabit speed is approximately 125 Megabytes per second. This is close to the speed you got.
> I put that drive an ICY BOX IB-1817M-C31 enclosure, with a maximum theoretical speed of 1000 MB/s.
Checks out, it has a 10Gb/s USB port.
The mistake is
> the USB controller of the Pi has a bandwidth of 4GB/s shared across all 4 ports
It's actually 4Gb/s = 512MB/s
Maybe there’s an alternative way to achieve what the author set out but increasing searchability at the cost of increasing brittleness isn’t it for me.
In this example:
const getTableName = (addressType: 'shipping' | 'billing') => { return `${addressType}_addresses` }
The input string and output are coupled. If you add string conditionals as the author did, you introduce the chance of a mismatch between the input and output.
const getTableName = (addressType: 'shipping' | 'billing') => { if (addressType === 'shipping') { return 'shipping_addresses' } if (addressType === 'billing') { return 'billing_addresses' } throw new TypeError('addressType must be billing or shipping') }
Similarly, flattening dictionaries for readability introduces the chance of a random typo making our lives hell. A single typo in the repetitions below will be awful.
{ "auth.login.title": "Login", "auth.login.emailLabel": "Email", "auth.login.passwordLabel": "Password", "auth.register.title": "Login", "auth.register.emailLabel": "Email", "auth.register.passwordLabel": "Password", }
Typos aren’t unlikely. In a codebase I work with, we have a perpetually open ticket about how ARTISTS is mistyped as ATRISTS in a similarly flat enum.
The issue can’t be solved easily because the enum is now copied across several codebases. But the ticket has a counter for the number of developers that independently discovered the bug and it’s in the mid two digits.
Years ago I ordered some T-Shirts to test and they were all fake versions that barely survived the first wash. Haven't ordered anything since then.