Live data from Hacker News

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

github.com

261–270 of 478 posts

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

#261

Earlier quoted context omitted.

create-react-app contains over 1000 packages. How long would it take to review all of those?

This sort of cavalier attitude where 1000 dependencies are yawn-inducing in their commonality is why I feel vindicated in never having wasted my time with this kind of ecosystem. Eventually the house of cards will come down. Let's all pray that it happens sooner rather than later.

I suspect that over time there will be more pushback against dependencies, as I've seen in other communities, viewing dependencies as liabilities carefully chosen.

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

#262

The problems that beset the Javascript ecosystem today are the same problems that beset the Unix ecosystem, back in the 90s when there still was one of those. TC39 plays the role now that OSF did then, standardizing good ideas and seeing them rolled out. That's why Promise is core now. But that process takes a long time and solutions from the "rough consensus and running code" period stick around, which is why instan…

> running code straight from wherever on the Internet it happens to live today. This, exactly this. Young me thought this was a point of the whole thingy we call Internet. And exactly that is what I like about QML from Qt. Just point to a file and that's it.

Go tried it; went over like a lead balloon. Theory; lead balloons don't fly anywhere.

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

#263

The problems that beset the Javascript ecosystem today are the same problems that beset the Unix ecosystem, back in the 90s when there still was one of those. TC39 plays the role now that OSF did then, standardizing good ideas and seeing them rolled out. That's why Promise is core now. But that process takes a long time and solutions from the "rough consensus and running code" period stick around, which is why instan…

> Deno appears to be trying to become the Linux of Javascript, through the innovative method of abandoning the concept of "package" entirely and just running code straight from wherever on the Internet it happens to live today.

I really like Deno for this reason. Importing modules via URL is such a good idea, and apparently it even works in modern browsers with ``. We finally have a "one true way" to manage packages in JavaScript, no matter where it's being executed, without a centralized package repository to boot.

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

#264
post #247

Earlier quoted context omitted.

So your point ultimately is that duck-typing isn't ideal? I mean, I agree, but I'm not sure where this gets us that we weren't before.

I don't actually mind duck-typing. My primary point is just that you are mistaken when claiming that this bug could only be surfaced by malicious code. My secondary (somewhat implicit) point is that having an "is-promise" function is a mistake when there is no way to tell if something actually is or is not a promise. This library/function name is lying to the programmers using it about what it is actually capable of,…

I mind duck typing! That's why I'm so fond of Typescript, where everything that shows up where a promise should be is reliably either instanceof Promise, or instanceof something that implements Promise, or a compile-time error.

Absent that evolved level of tooling, and especially in an environment still dealing with the legacy of slow standardization and competing implementations that I mentioned in another comment, you're stuck with best effort no matter what. In the case of JS and promises, because of the norm I described earlier in this thread, best effort is easily good enough to be going on with. It's not ideal, but what in engineering practice ever is?

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

#265
post #214
post #33

Digging into the reason behind breakage, the change is this one: https://github.com/then/is-promise/commit/feb90a40501c8ef69b... Which adds support for ES modules: https://medium.com/@nodejs/announcing-core-node-js-support-f... However the exports syntax requires a relative url, e.g. ‘./index.mjs’ not ‘index.mjs’. The fix is here: https://github.com/then/is-promise/pull/15/commits/3b3ea4150...

I wonder why people won't use yarn zero installs. They are great for having a reproducible builds and can work offline. You can have a CI and git hook which checks your code before deployment or pushing to git. Another way is to pin down the specific versions without ~ or ^ in the package.json so your updates don't break stuff.

Isn't this all stuff that you add after generating the project? For example yarn.lock is created on your first install. Having a pre-generated yarn.lock is a no-go because of the dubious decision to include the full path to the registry the package was sourced from.

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

#266
post #236

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.

Someone rolls out code where a serious bug fell through QA cracks, and appears to be breaking a mission-critical path. Your biggest client is on the phone screaming FIX IT NOW. Three hours is an eternity.

You roll back one version. Problem is fixed in thirty seconds.

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

#267

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.

In one of Robert "Uncle Bob" Martin presentation you may find the answer. The number of developers duplicates each 5 years. That means that any point in time half of the developers have less than 5 years of experience. Add to that realization the fact that inexperienced developers are learning from other inexperienced developers and you get the answer on why we repeat the same mistakes again and again.

I guess that is a matter of time that the reality changes, we will not duplicate the number of developers indefinitely and experience and good practices will accumulate.

Taking into account the circumstances, we are not doing so badly.

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

#268

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,…

Unless the packages you're adding are trivial I seriously doubt you're looking that close. Are you really going to code review 20000 lines of someone elses code every time you're adding something? 100,000? Also their dependencies? Those are very reasonable numbers by the way.

I do review a list of dependencies when I investigate which node package to use. For those for which I can choose, that is.

Sometimes I also take a look at the code.

And I've chosen the one with less dependencies often enough.

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

#269
post #126

The problems that beset the Javascript ecosystem today are the same problems that beset the Unix ecosystem, back in the 90s when there still was one of those. TC39 plays the role now that OSF did then, standardizing good ideas and seeing them rolled out. That's why Promise is core now. But that process takes a long time and solutions from the "rough consensus and running code" period stick around, which is why instan…

> Deno appears to be trying to become the Linux of Javascript Deno always sounded more "like the Plan 9 of Javascript" personally to be honest. It seems to be better (yay for built-in TypeScript support! Though I have my reservations about the permission management, but that's another discussion) but perhaps not better enough (at least just yet) to significantly gain traction.

The permissions management is a little tricky to think about at first, but once you get the hang of it I think it's actually quite nice. Setting strict permissions on CLI tools help to ensure that the CLI isn't doing anything nefarious when you're not looking (like sending telemetry data). Since this CLI has --allow-run, I can also have it execute a bin/server script that _does_ have network and read/write permissions, but only in the current app directory.

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

#270

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,…

create-react-app contains over 1000 packages. How long would it take to review all of those?

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