Live data from Hacker News

A one-line package broke `npm create-react-app`

github.com

411–420 of 478 posts

Re: A one-line package broke `npm create-react-app`

#411
post #270

Earlier quoted context omitted.

Too long. Therefor create-react-app is not useable for anything other than toy or hobby projects.

This. The problem isn't reading 1000+ dependencies, the problem is the 1000+ dependencies... There's no way, setting up a view renderer, in the context of a webpage, requires a 1000+ dependencies. I honestly did this exact thing with `create-react-app` and it's one of the reasons why I don't use/choose react. Too much bloat for no batteries included.

You're right there's no way. CRA isn't React. You can still use React by just adding react and react-dom to a page via two script tags.

Re: A one-line package broke `npm create-react-app`

#413

Earlier quoted context omitted.

And your example is why we have the "lol javascript trash amirite" chorus, because as you've noted these problems were solved decades ago. Yet for some reason, the JS and npm ecosystems always seem to have some dependency dustup once or twice a year.

Yes, that's largely my point. I'm not sure why it is surprising to see an ecosystem, twenty-five or so years younger than the one I compared it to, have the same problems as that one did twenty-five years or so ago.

25 years is roughly one generation. A new generation grows up, has no memory of the old problems?

Same with Covid, is roughly 20 years ago and people forgot there was SARS.

Re: A one-line package broke `npm create-react-app`

#414
post #170

every package can be a one line package if you minify it. lines of code as a metric for code quality is always relative. The fact that this is a one line package has nothing to do with the outcome. a one-line code change in a 5000 line dependency could just as much have messed up create-react-app. The size is irrelevant.

This is correct. Many tools are split into multiple packages for — hear me out — convenience.

I regularly extract features from my apps into new npm packages. This way they can be reused by other apps.

Troglodytes can keep copy-pasting code between apps while npm users publish once and update everywhere.

Re: A one-line package broke `npm create-react-app`

#415

Earlier quoted context omitted.

Then again, this broke a package that, by its very nature, isn't running in production. And the problem was solved within three hours. So I'm not sure how much everything-used-to-be-great-nostalgia is justified here.

My development environment is my production environment.

F

Re: A one-line package broke `npm create-react-app`

#416
post #50
post #7

And the source code of the library is: function isPromise(obj) { return !!obj && (typeof obj === 'object' || typeof obj === 'function') && typeof obj.then === 'function'; }

Wow just wow. So here's your new Promise object: class World { then () { return 0; } } isPromise(new World) // true If there really isn't a safe and better way to tell if an object is an instance of Promise…then color me impressed.

Your code is indeed an example of a promise. A stupid one, since it never “resolves”, but it’s a promise.

Re: A one-line package broke `npm create-react-app`

#417

I'm a developer, but I'm also on-call 24/7 for a Node.js application. The number of people here saying "this is why you don't use dependencies" or "this is why you vendor your deps" is frustrating to see. No one _but no one_ who has managed complex enough systems will jump on the bandwagon of enterprise-ready, monolithic and supported over something like Node.js. I'd trade in my JavaScript for J2EE about as fast as I…

J2ee was a hell, but Java EE was quite decent!

Pragmatism - do programming to solve real life problems rather than create a broken ecosystems which requires constant changes (and learning just to be on top of them) to fix a bad design

Re: A one-line package broke `npm create-react-app`

#418
post #73

I feel the real issue here is downstream package consumers not practicing proper dependency pinning. You can blame the Node ecosystem, the maintainer of the package, etc. but there are well-known solutions to prevent this kind of situation.

This wasn't a big problem due to a package being suddenly upgraded in existing code. It's because a scaffolding tool (Create React App) used to set up new projects would set those projects up with the latest (presumably patch, maybe minor) version of the dependencies. In other words, because those projects did not exist yet, there was nothing to pin.

Unless you mean Create React App should pin all of their (transitive) dependencies and release new versions multiple times a day with one of those dependencies updated.

Re: A one-line package broke `npm create-react-app`

#419

Call me crazy, but... I don't add things to my projects without looking at the source. Mostly because it saves me from shit like this. If I see something is small enough, and easy enough to reason about, I'll just copy-pasta that motherfucker with a comment citing the source and date it was pasta'd (license permitting). Things like this are so not worth a package, ever, it's something when you see it you go "oh yeah,…

Note that in this case the dependencies also include compilers (for several languages, because front-end projects use multiple languages, have to be compatible with varying levels of support for those languages, and there's some leeway for the consumer of the scaffolding tool as well to choose which toolchain they use - but the other options get installed as well). Do you also review the code of your compilers and runtimes? Test frameworks? Static analysers?

Re: A one-line package broke `npm create-react-app`

#420

Earlier quoted context omitted.

And your example is why we have the "lol javascript trash amirite" chorus, because as you've noted these problems were solved decades ago. Yet for some reason, the JS and npm ecosystems always seem to have some dependency dustup once or twice a year.

Yes, that's largely my point. I'm not sure why it is surprising to see an ecosystem, twenty-five or so years younger than the one I compared it to, have the same problems as that one did twenty-five years or so ago.

Pardon me if I've misunderstood you. I feel that this line of reasoning that excuses modern Javascript's mistakes on the basis of it being a young language to be spurious. We don't need to engineer new languages that recreate the mistakes of previous ones, or even worse, commit entirely new sins of their own. It's not like no-one saw the problems of the Node/JS ecosystem, or the problems of untyped languages, coming from a distance. Still, Node.js was created anyway. I would argue that it, along with many of its kindred technologies, has actually contributed a net deficit to the web ecosystem.
Post reply on HN