Arnout, 3rdEden

Its time that @npmjs , @github step up, take responsibility, and start protecting authors. Let me opt-out of exposing my email against my will.

Not only that, there is only 1 email address that is exposed, that is the same email npm uses for their communication, hence an easy phishing. As I use a dedicated alias for npm, i can also see that this public exposure is the reason I get so much spam. At least 40% is my alias

Just want to make it perfectly clear, @npmjs is 100% to blame for all the phishing attacks we package authors have to endure. Exposing the email address of authors for shits’n’giggles is 100% to blame for this. There is no option to prevent your email from being leaked by npm

Does any have a spare blsky invite? Seems like its time to move while twitter is on its way to implode. 🫣

@tlrobinson Its a great way to tell someone is a good or bad engineer.

Why do people use arrow functions for function declarations? In what world is export let myFunc = async ({ id }) => { better than export async function myFunc({ id }) { ?

TFW you find out the web finally has a deep clone API called `structuredClone`: 🥳 TFW you realise it doesn't work on Proxies: 😩

I really hate that this keeps happening.

TFW, you accidentally create another framework.

It's very liberating to work on your own projects, as you're not hindered by the constraints and boundaries of your work environment. You create. You experiment. You innovate. You're the mad scientist.

My dog has been responsible for 100% of the fires caused by our 2 @iRobot Roomba's. Long hair dogs, rotating parts == friction. It's a recipe for disaster.

Security researcher reporting bug: $100-1000 OpenSource maintainer fixing bugs: $0 🥲

The current state of the art mono repo tooling, nx/lerna, decided that fork bombing is an acceptable pattern when executing tasks. Is this _really_ the best we can do? Like, really?

Hot take: React did more harm than good for the web. Our apps got heavier, and we somehow accepted that is fine to ship duplicate content because yay hydration. It's extremely overkill for the majority of apps that just render basic UI elements.

@bahmutov While not without flaws either, I do agree, it solves a lot of the problems.

I'm thankful for JSDOM. For reminding about the mistake I made for installing it, and using it in a project. What were we thinking, trying to polyfil a JS environment with non functioning polyfill API's that do not represent the real world usage of our code at all.

It doesn't throw an Error, no, that would make too much sense right? Instead we create an Error instance, and log it to the console instead, sending you on a while goose chase figuring out where the error is coming from, why your tests are still passing.

Not only does it means you're not testing your code correctly and you basically cross your fingers and hope that there's no implementation difference between the real API and whatever polyfill they designed. But when you hit those API differences...

@MylesBorins @Raynos I understand the importance of 2FA on high profile packages to severely reduce the attack surface, but when the 2FA is forced upon you in these cases is should be on package basis, not account wide. This would severely reduce the friction on developers.

@3rdEden @Raynos It's definitely a challenge to find the balance between security and DX. We've made a bunch of improvements to the CLI 2FA experience but they aren't default yet. Honestly the new flow is even better than password based flow but is hidden behind a flag right now.

The npm 2FA login experience is terrible, I'm just never going to publish anything to npm again. No point maintaining modules, its not worth it.

@Raynos @MylesBorins I feel exactly the same. It feels like a punishment every time im forced into 2fa. Didn’t ask for, don’t want it, no way to opt out. I get it, some packages are high risk, but there’s better ways to solve it than taking npm accounts hostage.

@MylesBorins Cli. I couldn’t figure it out. I also keep getting annoying npm warnings that node 16 is deprecated. It’s just enough barrier / friction that I don’t care enough to maintain packages. It used to be a simple UX, no nagging.

@devongovett I have to disagree here. The bundler knows exactly which modules are bundled, and it decides to bundle multiple copies of it.

@3rdEden That doesn't make sense. If the package manager installs multiple versions, the bundler is going to use what's installed.

The way package managers like npm and yarn work seems totally backward for frontend development. They will happily install 10 different versions of a package to satisfy semver ranges, bloating bundles. There should be a mode to fail on install for conflicting versions instead.