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

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

github.com

Post reply on HN
Print view View original

151–160 of 478 posts

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

#151

Post by choward »

Can someone help me understand why a library like this is even necessary? Can't you just wrap everything and treat it like a promise?

    const aPromise = Promise.resolve(1);
    const notAPromise = 2;

    Promise.resolve(aPromise).then((x) => console.log(x));
    Promise.resolve(notAPromise).then((y) => console.log(y));

    // Logs:
    // 1
    // 2

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

#152

Post by staticassertion »

mikewhy wrote: post #111
staticassertion wrote: post #104

Earlier quoted context omitted.

Maybe I'm misunderstanding how those projects work. From what I recall, they generate a project, including the package.json. So I'm not sure why they couldn't just generate the package.json with pinned versions? I don't write much JS, and have only used create-react-app just a few times, so feel free to explain why this isn't possible.

package.json only lists top-level dependencies. package-lock.json tracks all dependencies, and dependencies of dependencies. is-promise is one of those dependencies of a dependency, which you don't have much control over.

How would a top level dependency change versions if it bumped a transitive dependency? Is that a thing in js-land?

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

#153

Post by diggan »

russtrotter wrote: post #105

is it idiomatic in the JS world to always express dependencies in the "version X.Y or higher", vs "version X.Y"? Most of my experience is from the java/maven world where you're playing with fire if you don't just make it "X.Y".

It's less about JS and more about semantic versioning (semver). So you're supposed to be able to expect that the API interface of the library is not changing on the second or third version number, only on the first one, in this format: MAJOR.MINOR.PATCH

But as we're still doing human versioning one way or another in package management, there will always be cases where it doesn't perfectly follow its versioning scheme or otherwise behaves unexpectedly because of a change. It's almost like we need new ways of programming where the constructs and behavior of the program/library are built up via content-addressing so you can version it down to it's exact content.

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

#155

Post by throwanem »

IAmEveryone wrote: post #149
throwanem wrote: post #107

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…

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.

Only as much as it ever is. That's why I'm making fun of it.

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

#156

Post by staticassertion »

alerighi wrote: post #130
staticassertion wrote: post #45

Earlier quoted context omitted.

Here's my off-the-cuff take that will not be popular. A function like this should be a package . Or, really, part of standard js, maybe. A) The problem it solves is real. It's dumb, but JS has tons of dumb stuff, so that changes nothing. Sometimes you want to know "is this thing a promise", and that's not trivial (for reasons). B) The problem it solves is not straightforward. If you Google around you'll get people sa…

Lile... x instanceof Promise It works for standard promises, sure there are non standard promises, ancient stuff, that to me shouldn't be used (and a library that uses them should be avoided). So why you need that code in the first place? Also that isPromise function will not work with TypeScript, imagine you have a function that takes something that can be a promise or not (and this is also bad design in the first p…

1) I'm not defending the implementation of is-promise. I don't care to, I'm not a javascript developer.

2) > sure there are non standard promises, ancient stuff, that to me shouldn't be used

If you're building a library, or maintaining one that's been built over many years, you can't easily make calls like that.

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

#157

Post by aylmao »

jackewiehose wrote: post #49

I think these one-line-packages aren't the right way to go. Either JS-developers should skip the package-system in that case and just copy and paste those functions into their own project or there should be more common used packages that bundle these one-liners. I mean is_promise() and left_pad() are not worth their own package. Packages-dependencies of 10000 packages for trivial programs are just insane. Is someone…

I see a lot of criticism to one-line packages, but IMO in the end what matters is the abstraction.

Thinking of the package as a black box, if the implementation for left-pad or is-promise was 200 lines would it suddenly be ok for so many other packages to depend on it? Why? The size of the package doesn't make it less bug-prone.

I see plenty of people who are over-eager to always be up-to-date, when there really isn't any point to it if your system works well, and so they don't pin their versions. This will break big applications when one-line packages break, but also when when 5000-line packages break. Dependencies are part of your source, don't change it for the sake of changing it, and don't change it without reviewing it.

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

#158

Post by Twirrim »

btilly wrote: post #119
montroser wrote: post #43

Everyone crying about this on the Internet would do better to just take it as an easy lesson: pin your dependency versions for projects running in production. This was an honest oversight, and even somewhat inevitable with so many expected supported ways to import/export between cjs mjs amd umd etc. It will happen again. And when it happens the next time, if it ruins your life again, take issue with yourself for not…

And everyone who depends on projects that pin their dependency versions gets to be victims of security exploits long after they are fixed. Dependency management is not as simple as you seem to think.

Tools like Safety can help in the python world, https://pypi.org/project/safety/, and cargo-audit https://github.com/rustsec/cargo-audit in the rust world. Stick them in your build chain and get alerted to dependencies with known exploits, so you can revisit and bump your dependency versions, or decide that that project is not worth using if they can't be bothered to consider security to be as important a feature as it is.

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

#159

Post by andrewzah »

exogen wrote: post #106
andrewzah wrote: post #86

Earlier quoted context omitted.

No. Other languages don't publish/import packages that are one line of code . I have never seen an issue like this with any other language that I've worked with. Any sane developer that needed a one-liner like this would just manually implement it. Not to mention that these sorts of functions are unnecessary in languages with a good stdlib or statically typed languages like rust, etc.

Know what happens every time people like you say this here on HN? They post the one-liner they would have manually implemented in their code base and it's wrong . The one that comes to mind is the "is-negative-number" package. Yes, the geniuses of Hacker News, after finding out there was an npm package for determining whether something was a negative number, could not correctly implement that function. You and everyo…

> COULD NOT CORRECTLY IMPLEMENT THAT FUNCTION

As opposed to blindly trusting and adding a dependency for a random library with a one liner?

I don't think the "don't roll your own crypto" argument really applies here. Of course we can come up with hypothetical situations where developers are incompetent or don't test their code at all. This includes armchair analysis for a post on HN, by non-javascript developers.

I would argue that it's still better than adding a dependency. Heck, you could even copy/paste the correct code.

I know I'm not a perfect programmer, so important functionality like this gets unit tested as necessary. :-)

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

#160

Post by krapp »

jackewiehose wrote: post #134
krapp wrote: post #112

Earlier quoted context omitted.

Not everyone would use it, that's my point. The inertia behind the existing system is too great, especially in enterprise. All that would happen is that library would become just another Node package, and then you've got the "n+1 standards" problem. The "nonexistent standard library" wasn't a problem in the days when javascript development meant getting JQuery and some plugins, or some similar library. It only became…

> Not everyone would use it If the right people would provide the library, it would be used by enough people. > Yes, in my mind you'd have to change everything from the ground up, starting with no longer using javascript outside of the browser Whats the point of inside or outside of the browser?

The point is that different languages are best suited to different tasks. Javascript is a simple, very loosely typed scripting language with prototypal inheritance that was developed to be run in the browser. It's a DSL, not a general purpose programming language. Using it elsewhere for applications where another language with stronger and more expressive types would be more appropriate requires hacks like compiling it from another (safer, more strongly typed) language like Typescript, which still results in code that can be fragile because it only simulates (to the degree that a JS interpreter allows) features that the language doesn't actually support.

See the attempt to "detect if something is a Promise" as an example - the function definition for the package makes it appear as if you're actually checking a type, but that's not what the package does.

Most of the unnecessary complexity in modern JS, as I see it, comes from the desire to have it act and behave like a language that it simply isn't.

Post reply on HN