Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Upcoming breaking changes for npm v12

github.blog

Post reply on HN
Print view View original

81–90 of 221 posts

Re: Upcoming breaking changes for npm v12

#81

Post by altmanaltman »

shagie wrote: post #12
aniceperson wrote: post #2

didn't know npm was owned by github.. well, that explains things...

NPM Is Joining GitHub - https://news.ycombinator.com/item?id=22594549 (March 16, 2020; 571 comments; 1829 points) - https://github.blog/news-insights/company-news/npm-is-joinin... Some of it aged... interesting. Top comment: > Microsoft doesn’t do everything right but the GitHub acquisition has honestly gone better than I ever expected. Rather than forcing GitHub to adopt Microsoft centric policies, Microsoft has ado…

it was all good until AI entered the chat

Re: Upcoming breaking changes for npm v12

#82

Post by altmanaltman »

shimman wrote: post #79
luckman212 wrote: post #76

Earlier quoted context omitted.

> I'd expect the trillion dollar transnational corporation to do right you would? has any trillion dollar corporation ever?

No, and that's why we must destroy them. Figuratively then literally.

Destroy what exactly? And replace with what?

Re: Upcoming breaking changes for npm v12

#83

Post by z33k »

tyre wrote: post #80
ok_dad wrote: post #56

Earlier quoted context omitted.

Young people thought M$ was changing, the old folks knew it was just another cycle of embrace, extend, extinguish.

Young people were… right? VS Code is open source. (Cursor is built on it!) GitHub didn’t embrace, extend, extinguish git. You can git push to a different company (e.g. Gitlab) and you’ve migrated. The biggest problems with GitHub are scaling and availability, not lock-in. Microsoft today is nothing like it was 30 or 20 years ago. Fifteen years ago we were writing HTML and JavaScript specifically for Internet Explorer…

Good luck migrating the ”forge” part with the ”git” part. Your github org settings, pull requests, rulesets, CI/CD pipelines, containers, copilot... The lock-in always comes from the ”forge” part, never the ”git” part.

Re: Upcoming breaking changes for npm v12

#85

Post by albedoa »

tyre wrote: post #80
ok_dad wrote: post #56

Earlier quoted context omitted.

Young people thought M$ was changing, the old folks knew it was just another cycle of embrace, extend, extinguish.

Young people were… right? VS Code is open source. (Cursor is built on it!) GitHub didn’t embrace, extend, extinguish git. You can git push to a different company (e.g. Gitlab) and you’ve migrated. The biggest problems with GitHub are scaling and availability, not lock-in. Microsoft today is nothing like it was 30 or 20 years ago. Fifteen years ago we were writing HTML and JavaScript specifically for Internet Explorer…

[flagged]

Re: Upcoming breaking changes for npm v12

#86

Post by beezlewax »

tyre wrote: post #80
ok_dad wrote: post #56

Earlier quoted context omitted.

Young people thought M$ was changing, the old folks knew it was just another cycle of embrace, extend, extinguish.

Young people were… right? VS Code is open source. (Cursor is built on it!) GitHub didn’t embrace, extend, extinguish git. You can git push to a different company (e.g. Gitlab) and you’ve migrated. The biggest problems with GitHub are scaling and availability, not lock-in. Microsoft today is nothing like it was 30 or 20 years ago. Fifteen years ago we were writing HTML and JavaScript specifically for Internet Explorer…

Do microsoft own git now?

I don't think so

Re: Upcoming breaking changes for npm v12

#88

Post by pjio »

grassfedgeek wrote: post #16
TZubiri wrote: post #5

Looks good? But doesn't this just change the compromise window from first installation to first run?

"First run" doesn't exist for JavaScript libs used only in web apps. So for that entire class of packages this change makes them safe.

> So for that entire class of packages this change makes them safe.

This is misleading. The change addresses one important attack vector. But if one runs the application directly on the host for development, if the package is imported like pointed out in the other comments or the package intends to steal user credentials from production, it is far from "being safe". Safer, but still needs scrutiny.

Post reply on HN