47 ms·

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

599 points by tessela 6y ago

TechBro8615 6y ago
The package referred to in the clickbait title is `is-promise`
- ajross 6y ago
  I don't know how "clickbait" that title can be when it is, in fact, longer than the line of code in question: declare function isPromise<T, S>(obj: Promise<T> | S): obj is Promise<T>; This is, indeed, the only line of exported code in the entire package. I genuinely don't understand the NPM world.
  - jakear 6y ago
    That's just the type definition. Think of it like the .h if you're into that sort of thing.
  - redmorphium 6y ago
    Me neither. I can't wait for Deno 1.0 next month. https://deno.land/ https://deno.land/
    - stickac 6y ago
      How exactly will the new runtime fix the habit of Javascript developers to pull-in millions of dependencies?
    - freeqaz 6y ago
      What is this exactly? The website is a bit unclear.
      - jpangs88 6y ago
        I was wrong about what this was I have edited this comment
        eropple 6y ago
        Why would a Rust wrapper around the C++ project that is V8, which implements a garbage-collected programming language and environment, "use less ram" just by virtue of some parts of it being written in Rust?
        deleted 6y ago
        [deleted]
      - frank2 6y ago
        Deno is much like node (uses the V8 engine, does not require a browser) and was created by the man who created node.
    - jpangs88 6y ago
      Makes me look forward to this more https://romejs.dev/ https://romejs.dev/ since one of the ideas is that it will have no third party dependencies...
  - hn_throwaway_99 6y ago
    > I genuinely don't understand the NPM world. You're right, you don't. What you posted is just the function declaration, not the implementation.
    - deleted 6y ago
      [deleted]
  - hughes 6y ago
    I think it reflects how the evolution of the JS ecosystem strongly resembles natural evolution. This package is now a vestigial organ, but there was a time when it served a useful purpose. Other packages formed connective tissue to this package, and since those package may still be useful, this one has stuck around.
  - deleted 6y ago
    [deleted]
  - svnpenn 6y ago
    NPM is the answer to the question: what would happen if everyone refused to use any idioms ever, and instead replace them all with packages? God help you, if you import a JavaScript (or Rust) package today. Lest you fall in a gaping chasm of endless cascading dependencies.
    - linkdd 6y ago
      It's not NPM's fault, it's developer's fault. I would never in my right mind publish a one-line package, Python, Javascript, whatever. And I would never add a one line package as dependency
- Lammy 6y ago
  Does the package name need to be in the title if it's already the URL? :)
  - deleted 6y ago
    [deleted]
- tzs 6y ago
  How would you rewrite the title to not be clickbait?
  - detaro 6y ago
    "1-line package "is-promise" broke `NPM create-react-app`" ?
  - TechBro8615 6y ago
    I would include the name of the package.
- dang 6y ago
  The title doesn't strike me as clickbait. The significant thing is what happened.
  - TechBro8615 6y ago
    Personally as a JS dev, the significant thing is which package it was. These stories happen all the time, so when I see them I’d rather know which package it is at a glance so I know if I’m affected.
    - capableweb 6y ago
      Fun thing with building applications overusing npm is that you usually don't know exactly what packages you have. Not until you check for the specific package, so you probably don't "know at a glance" if you're affected or not.
      - TechBro8615 6y ago
        Hah, true. I got bit by one of these two days ago where the offending package was trying to install node itself (wtf?). It was two levels deep of `yarn why` before I figured out the issue. Fortunately I've been around long enough that the first thing I did was check the package for github issues... sure enough, found a 5 hour old issue with a bunch of people complaining of failing builds. If I hadn't searched first, I probably would have banged my head for another couple hours...
0xff00ffee 6y ago
This is why regression suites are important. EDIT: I wasn't dissing the developers. They have regression, this was just an accident. I was stating it is important. My bad (too late to delete).
- SSchick 6y ago
  The package does have CI setup, however the test matrix does not cover the latest node versions (which are the ones that are affected). See https://github.com/then/is-promise/blob/master/.travis.yml https://github.com/then/is-promise/blob/master/.travis.yml (missing v11, v12, v13, v14)
  - RyJones 6y ago
    And CI is failing[0]. [0]: https://travis-ci.org/github/then/is-promise/builds https://travis-ci.org/github/then/is-promise/builds
    - SSchick 6y ago
      The failing CI here is unrelated to the issue but it's still pretty bad a release was made with failing CI.
      - jessaustin 6y ago
        It was a five-year release (followed quickly by a 3.5-hour release and a sub-minute release) [0], so they may not have wanted to dig into CI. [0] https://github.com/then/is-promise/releases https://github.com/then/is-promise/releases
- seibelj 6y ago
  Install any moderately complex nodejs lib or app and it will throw tons of warnings, ignored errors, and security issue alerts. As you should with any app running in production, lock down everything and watch network traffic because there are innumerable backdoors in the JavaScript ecosystem.
SSchick 6y ago
Probably also broke eslint too since `is-promise` is also a sub-dependency of that as well. This is much less of an issue when using a lockfile, at least for existing packages/projects.
esaym 6y ago
You had one job...
chvid 6y ago
And the source code of the library is: function isPromise(obj) { return !!obj && (typeof obj === 'object' || typeof obj === 'function') && typeof obj.then === 'function'; }
- artursapek 6y ago
  My prior decision to never work with JavaScript again has just grown firmer.
  - mothsonasloth 6y ago
    I second this, JavaScript Devs are near the bottom of the food chain, just above VB Devs. Myself as a Java developer is middle of the pyramid. The apex predators are embedded developers, followed by c Devs then game Devs.
    - smt88 6y ago
      It's not useful, interesting, or accurate to stratify people this way. You have no idea what someone's intelligence level or background is based on their usage of JS or C. I loathe JS, but one of the best devs I know likes it. People's mileage varies. For me personally, there's much more money in easy React products than making games. I'm not a great dev, but I'd be doing this same work even if I were.
    - TechBro8615 6y ago
      The “food chain?” What do you mean by that?
      - deleted 6y ago
        [deleted]
    - gombosg 6y ago
      I sincerely hope you're being sarcastic here.
ng12 6y ago
Looks like it broke @angular/cli too.
- Noumenon72 6y ago
  Who does this affect? I just did npx @angular/cli new hello-world-project and that worked. I have remote Angular training on Monday and didn't want to do a global install.
  - ng12 6y ago
    It's already been patched with version 2.2.1.
tholman 6y ago
Hmm, I had some problems with a nested `is-object` dependency when updating some deps last week, I wonder if it’s related.
sergiotapia 6y ago
The javascript ecosystem is a total house of cards, "webshit" as they call it in some other sites, rings true more and more.
- _greim_ 6y ago
  Agreed. Libraries and tools often don't work in a straightforward manner. Lots of tools reach below the surface and do their own tampering and monkey-patching of the runtime, module system or environment. Layer upon layer gets deposited over time. It's like doing construction on topsoil riddled with unmarked gas, water, and electrical lines.
brown9-2 6y ago
There is something aggravating about the first comment in an issue like this posted minutes after the issue was created to say “is this fixed yet?”
- deleted 6y ago
  [deleted]
- ehsankia 6y ago
  The worst part is that it was posted 10 minute later... I understand bumping a year old issue, but cmon give it a few minutes at least.
  - luckylion 6y ago
    It was posted after chore: fix is-promise, they may have not realized that it's just some random pingback that github shows there, and not a message that somebody has committed a fix.
gav 6y ago
Digging into the reason behind breakage, the change is this one: https://github.com/then/is-promise/commit/feb90a40501c8ef69b0c65bdf1eb703182214407#diff-b9cfc7f2cdf78a7f4b91a753d10865a2 https://github.com/then/is-promise/commit/feb90a40501c8ef69b... Which adds support for ES modules: https://medium.com/@nodejs/announcing-core-node-js-support-for-ecmascript-modules-c5d6dc29b663 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/3b3ea4150d9a0788ed467d0c05a7e67f5070e32a https://github.com/then/is-promise/pull/15/commits/3b3ea4150...
- searchableguy 6y ago
  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.
  - ng12 6y ago
    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.
  - jrochkind1 6y ago
    What's "yarn zero installs"? Googling did not do it for me.
    - _630w 6y ago
      Instead of node_modules containing source code of the packages, yarn generates a pnp.js file which contains a map linking a package name and version to a location on the disk, and another map linking a package name and version to its set of dependencies. All the installed packages are stored in zip form in .yarn/cache folder to provide a reproducible build whenever you install a package from anywhere. You can commit them to version control. Unlike node_modules, they are much more smaller in size due to compression. You will have offline, fully reproducible builds which you can test using a CI before deployment or pushing code to repository https://yarnpkg.com/features/zero-installs https://yarnpkg.com/features/zero-installs
andrew_ 6y ago
It's downloaded 11 million times a week. This touches a good majority of the Node ecosystem, so there's going to be quite a lot that doesn't work until this is remedied. And I'm not sure that package-lock.json is going to save folks here because it was a minor version update. https://www.npmjs.com/package/is-promise https://www.npmjs.com/package/is-promise
- remram 6y ago
  Doesn't the lock file lock exact versions?
- roonyh 6y ago
  package-locks lock down exact versions. Otherwise there's no point to them.
zulgan 6y ago
Chill with the js hate, this happens everywhere. Maybe not to this extend, but if X (where X is whatever you are thinking about) had similar amount of people using it (especially junior people) this would happen there as well.
- ddevault 6y ago
  No, this does not happen everywhere. Show me this happening in Debian.
  - RussianCow 6y ago
    You can't use the very latest version of any software in Debian at all without adding a custom repository, at which point you have the same issue. So the comparison is not apples to apples.
    - quantummkv 6y ago
      How about a rolling release like openSUSE tumbleweed then? I have been using it for years, I generally update once a week and I have never broken my system due to an update. Never.
    - ddevault 6y ago
      You can use Debian Unstable, or maybe just use stable and reliable dependencies so that your software is also stable and reliable. That would require putting in some effort, though, and we can't be having that, can we?
      - RussianCow 6y ago
        You can do that with NPM if you pin your dependencies to exact versions, which is the same solution that you would use for any other package manager, and basically what Debian and other Linux distros do for you. I don't know why you think this problem is somehow unique to NPM or the JavaScript ecosystem.
montroser 6y ago
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 pinning your dependency versions, rather that package maintainers trying to make it all happen.
- tgv 6y ago
  > pin your dependency versions And then to see "npm detected 97393 problems" or whatever the message exactly is.
  - acdha 6y ago
    That’s good: it’s easy to update and it means you do it in a controlled manner rather than the next time something deploys.
  - montroser 6y ago
    You don't need to pin them forevermore -- just when you don't want everything to break unexpectedly :). When you want to upgrade your dependencies, then go ahead and do that, on your own schedule, with time and space to fix whatever issues come up, update your tests, QA, etc.
- mikewhy 6y ago
  > pin your dependency versions for projects running in production Works for existing apps, but people using create-react-app and angular CLI can't even start a new project.
  - staticassertion 6y ago
    I don't know much about those projects, but why did this break them? Are they not pinning versions?
0x7265616374 6y ago
You can thank https://twitter.com/ForbesLindesay https://twitter.com/ForbesLindesay for breaking Node today.
- eropple 6y ago
  This is nothing but an attempt at brigading. Get out of here with this.
jackewiehose 6y ago
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 going to fix that?
- krapp 6y ago
  >Is someone going to fix that? Probably not. There is too much code in the wild, and NPM owns the entire JS ecosystem, and there has been too much investment in that ecosystem and its culture at this point for a change in course to be feasible. The JS universe is stuck with this for the foreseeable future.
  - jackewiehose 6y ago
    Does it need much to change? I didn't mean to fix NPM. The problem is the non-existing standard-library. Just create one that everybody will use and everybody could cut their dependencies by thousands.
    - krapp 6y ago
      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 a problem after the ecosystem got taken over by a set of programming paradigms that make no sense for the language. Yes, in my mind you'd have to change everything from the ground up, starting with no longer using javascript outside of the browser.
      - jackewiehose 6y ago
sneak 6y ago
I hope that more packaging systems take the go modules approach and cryptographically and immutably identify their dependencies at time of addition to the project. This sort of breakage shouldn’t be possible.
- dnautics 6y ago
  I'm sorry if you were unaware, but they absolutely do that, and were doing that long before go was.
  - sneak 6y ago
    I am aware of package lockfiles. If deps are immutable, then nothing anyone does in any other package (short of having the package repository take the code down) should be able to break your future builds. If that were true, TFA would not be news.
    - dnautics 6y ago
      I'm not a node expert but i believe the problem is that most people auto-update their node dependencies (I know I do, but I only have to do it rather rarely, since I don't primarily use node), because there are just so often minor security regressions that need to be fixed.
    - n_e 6y ago
      > If deps are immutable, then nothing anyone does in any other package (short of having the package repository take the code down) should be able to break your future builds. They are. You're only affected if you don't use a package-lock.json or start a new project (which will pull the latest versions of the dependencies).
- jen20 6y ago
  This kind of breakage is perfectly possible in Go also - though the most common equivalent of "left-pad broke my project" for many Go developers is "X changed the case of their GitHub username and now all my import paths are broken".
odensc 6y ago
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.
- thawkins 6y ago
  So you would exchange security for stability, if you use package pinning then you will end up with fosilized packages in your product, which will have all maner of security issues that have alresdy been fixed.
  - flukus 6y ago
    If a package doesn't provide a stable branch that will receive security updates then it's not mature enough to be used anyway. That's the sensible middle ground between bleeding edge and security, unfortunately most packages/projects aren't mature enough to provide this. There's a reason companies stick with old COBOL solutions, modern alternatives simply aren't stable enough.
  - deleted 6y ago
    [deleted]
  - linkgoron 6y ago
    You can always use something like dependabot, which should help you quickly upgrade versions and also protect you from breaking your build.
  - rhizome 6y ago
    I get notifications to update my Rails apps from GitHub as a matter of course when there's a CVE in my dependencies. Does this kind of thing not exist/is impractical for JS?
    - hobofan 6y ago
      From my experience of getting ~30 of those notifications per week for a handful of JS repos, I can very much assure you that it does exist.
ConcernedCoder 6y ago
mrw you're using a package to do a type-check: return !!obj && (typeof obj === 'object' || typeof obj === 'function') && typeof obj.then === 'function'
deleted 6y ago
[deleted]
jbverschoor 6y ago
Is this news? Happened so many times before. NPM is broken. Yarn 2.0 is never gonna take off. These problems have been fixed long before. Waste of life.
kingbirdy 6y ago
The the broken package just released a fix: https://github.com/then/is-promise/releases/tag/2.2.1 https://github.com/then/is-promise/releases/tag/2.2.1
russtrotter 6y ago
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".
- throwanem 6y ago
  There are a lot of idioms. A very common one, I think the current default, is to pin only the major version in the dependency list, and also to lock exact versions in an installer-generated lockfile following a successful install. If you find a locked version breaks your code, you adjust your dependency list, nuke the lockfile, and let a reinstall build it again. The idea is that pinning major versions lets you get non-breaking improvements from package authors who use semver properly, and pinning exact known-good versions lets you avoid surprises in your CI builds. It works pretty well when you start from a known good state and vet your dependencies reasonably well. The trouble here seems to be largely that CRA is designed, among other purposes, to serve people just getting into the ecosystem of which it's a part, and those people are unlikely to be familiar enough with the details I've described to be able to effectively respond. The comparison with left-pad is easy, but this isn't at all on the same scale. It's a bad day for newbies and a minor annoyance for experienced hands. And, of course, cause for endless spicy takes about how Javascript is awful, but such things are as inevitable as the sunrise and merit about the same level of interest.
- n_e 6y ago
  The "idiomatic way" is to use a package-lock.json, which keeps the dependencies (and transitive dependencies) at the exact version specified unless you decide to upgrade them.
- diggan 6y ago
  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.
throwanem 6y ago
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 instanceof Promise isn't enough of a test for things whose provenance you don't control. Of course, such a situation can't last forever. If the idea is good enough, eventually someone will come along and, as Linux did to Unix, kill the parent and hollow out its corpse for a puppet, leaving the vestiges of the former ecosystem to carve out whatever insignificant niche they can. Now the major locus of incompatibility in the "Unix" world is in the differences between various distributions, and what of that isn't solved by distro packagers will be finally put to rest when systemd-packaged ships in 2024 amid a flurry of hot takes about the dangers of monoculture. Bringing it back at last to the subject at hand, 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. As a former-life devotee of Stack Overflow, I of course applaud this plan, and wish them all the luck they're certainly going to need. The impetus behind "lol javascript trash amirite" channer takes today is exactly that behind the UNIX-Haters Handbook of yore. I have a printed copy of that, and it's still a fun occasional read. But those who enjoy "javascript trash lol" may do well to remember the Handbook authors' stated goal of burying worse-is-better Unix in favor of the even then senescent right-thing also-rans they favored, and to reflect on how well that played out for them.
- morelisp 6y ago
  This analogy doesn't hold up at all. The UHH is a fun read, yes, but the biggest real-world problem with the Unix Wars was cross-compatibility. Your Sun code didn't run on Irix didn't run on BSD and god help you if a customer wanted Xenix. OK, you can draw some parallel here between React vs. Vue vs. Zeit vs. whatever. But there was also the possibility, for non-software businesses, to pick a platform and stick to it. You run Sun, buy Sun machines, etc. That it was "Unix" didn't matter except to the software business selling you stuff, or what kind of timelines your in-house developers gave. There is no equivalent in the JS world. If you pick React, you're not getting hurt because Vue and React are incompatible, you're getting hurt because the React shit breaks and churns. Every JavaScript community and subcommunity has the same problem, they keep punching themselves in the face, for reasons entirely unrelated to what their "competitors" are doing. Part of this is because the substrate itself is not good at all (way worse than Unix), part is community norms, and part is the piles of VC money that caused people to hop jobs and start greenfield projects every three months for 10 years rather than face any consequences of technical decisions. Whatever eventually hollows out the mess of JS tech will be whatever figures out how to offer a stable developer experience across multiple years without ossifying. (And it can't also happen until the free money is gone, which maybe has finally come.)
bambataa 6y ago
create-react-app was broken a couple of weeks ago when I tried to use the Typescript template. Some dependency in Jest had been changed to require a version of Typescript that had only been out for a few weeks, breaking everything (including create-react-app) that hadn't updated to the latest tsc. What an ecosystem.
deleted 6y ago
[deleted]
CapriciousCptl 6y ago
Someone somewhere is going to organize a series of JS packages with the continuity of a standard library and full of verification and tests. Sane versioning, consistent interfaces and so on. The npm ecosystem isn't bad it's just unwieldy successful.
rubyn00bie 6y ago
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, that's the obvious, easy way of doing this" it's not a package, it's a pattern. I can promise you, this was only ever added to packages because people wrongly assumed because since it's about "promises" (spooooky) it must be complex and worthy of packaging. As someone who doesn't do front-end work regularly, but also sank about 3 consecutive weeks (~6-8 hours/day) in the last year into understanding generators, yielding, and promises... I can tell you, the actually scary part about all of this, is pretty much no one just reads the fucking docs or the code they're adding. Moral of the story, especially in the browser: the reward of reading the code before adding it is enormous, you'd be surprised how often the thing you want is just a simple pattern. Taking that pattern and applying it to your specific use case, instead of imposing that pattern on your use case will give you giant wins.... Learn the patterns and you're set for life.
- xyst 6y ago
  tbh, it's something that should be included in a standard library (not a third party package or dependency)
  - globular-toast 6y ago
    Or just copy and paste it into your project. Using a dependency for one line is beyond ridiculous.
- ganstyles 6y ago
  I wish I had as much time as you. Looking through the source code of the millions and millions of lines of code that get packaged with any modern application before you add things to your projects sounds daunting!
- bdcravens 6y ago
  create-react-app contains over 1000 packages. How long would it take to review all of those?
xyst 6y ago
Now I understand the reasoning behind the Golang suggestion to commit the /vendor directory.
choward 6y ago
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
- jhanschoo 6y ago
  For compatibility with old versions of JS without Promise, when libraries used thenables or a promise library.
- franciscop 6y ago
  Somehow convoluted, but if you wrap in a promise like this then you make it async (similar to setTimeout(fn, 0)), so in some situations you might want to keep the non-promised code as non-promise: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... (red is async, blue is sync)
- turnipla 6y ago
  This is not a library. Stop thinking of it as a library. It's a building block, a module. > why a library like this is even necessary? Do you know how to determine whether something is a Promise? Wrong. Also the first few StackOverflow answers are wrong or incomplete. You know what's better? Using the same library 3.4 million repos depend on, that is tested and won't break if you use a package-lock. > Can't you just wrap everything and treat it like a promise? Maybe. Maybe not. Treating everything as a Promise means you have to make your function asynchronous even if not necessary.
c-smile 6y ago
Weinberg's Law: If Builders Built Buildings the Way Programmers Wrote Programs, Then the First Woodpecker That Came Along Would Destroy Civilization.
- blast 6y ago
  That's the soft in software.
- Ididntdothis 6y ago
  This sounds very clever but the nature of software development is quite different from building buildings. The rate of innovation is by magnitudes higher. And as opposed to buildings software can tolerate a certain amount of failure.
  - rhizome 6y ago
    "Pfft. Chickens don't even know what a road is!"
- sipos 6y ago
  Why are So Many of the Words in This Comment Capitalised? Is it a Title of Something?
janpot 6y ago
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.
- xyst 6y ago
  how about "single function" instead?
- turnipla 6y ago
  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.
jrockway 6y ago
A little copying is better than a little dependency.
unwoundmouse 6y ago
nvm
- searchableguy 6y ago
  Read the linked post.
  - unwoundmouse 6y ago
    FUCK I thought the linked article described the situation
    - tomphoolery 6y ago
      way to read the article before commenting
- droidist2 6y ago
  Isn't this the story of leftpad?
antibland 6y ago
One reason why we may have one line packages is the demand FAANG places on applicants. On three job screens from three different companies, I was asked, "Which npm packages have you created that we'd know about?" For many who are hell-bent on entering these companies, yet have no known packages under their belt, they very well might fire off a one line package that actually gets some downloads, to be better "prepared" when screened.
dgellow 6y ago
As always: vendor your dependencies.
- ojr 6y ago
  vendoring my dependencies wouldn't save me from a rare issue I had dealing with npm packages, for example I had a package that relied on an underlying api call to a machine learning cloud api, the api call became deprecated. Not writing code is the only sure way to have no bugs.
- lpghatguy 6y ago
  Using package-lock.json gives you the same effect.
- turnipla 6y ago
  Good luck vendoring node_modules. Why are these threads filled with people who know nothing about node? npm and yarn both have lockfiles for this purpose. Vendoring only bloats your repos.
  - dgellow 6y ago
    > Why are these threads filled with people who know nothing about node? That’s a quite bad assumption from your part based on almost no information. I don’t know about the rest of the thread but I’m personally quite familiar with node. A lock file doesn’t fix the same issues vendoring does. The lock file gives you an explicit list of version used, vendoring save the exact copies of the dependency with the rest of your code. By vendoring anyone who is working on the project is using the exact same version of a dependency, AND you don’t have to care about an external provider (the registry being up, etc, that’s way easier for you CI too), AND you can review dependencies upgrade via git as if it was your code. Of course that’s a mess when the JavaScript ecosystem has an infinite amount of dependencies for a hello world.
worik 6y ago
Why NPM? I think that is the real question I do not see anybody asking. SO I will... Why NPM?? What is the point?
- worik 6y ago
  Right. No point at all. A waste of time and a yawning security hole
ashtonkem 6y ago
The fact that this has broken serverless for people is reinforcing my priors in a big way.
cryptoquick 6y ago
Does anyone know if there's a way to upgrade a dependency of a dependency of a dependency of a dependency of a dependency in my yarn.lock without actually editing the yarn.lock, and also, waiting for five packages to update their dependencies, especially if they're locked or specified by even one of the five in semver rules? For example: Running `yarn why is-promise` in a CRA app: `Hoisted from "react-scripts#react-dev-utils#inquirer#run-async#is-promise"` Currently, running a `yarn upgrade-interactive --latest` doesn't indicate there are any updates, so presumably, this is still a problem upstream. Also, if anyone's in a pinch right now, luckily enough, I made this yesterday, for an interview I had only a couple hours ago. I lucked out! But if anyone else might need it, maybe it'll help someone: https://github.com/cryptoquick/demo-cra-ts https://github.com/cryptoquick/demo-cra-ts Oh, and, uh, pardon the pun... :/
- acemarke 6y ago
  Per other comments in the thread, this is the primary use case for Yarn's "resolutions" feature: https://classic.yarnpkg.com/en/docs/selective-version-resolutions/ https://classic.yarnpkg.com/en/docs/selective-version-resolu...
  - cryptoquick 6y ago
    Thanks! Tried, it seems to work! Repo updated, too. This seems to be what it does, for those curious: https://github.com/cryptoquick/demo-cra-ts/commit/5c84aa48e9409478a6b19e2f065fa99313d6b10f https://github.com/cryptoquick/demo-cra-ts/commit/5c84aa48e9...
erulabs 6y ago
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'd quit tech and move up into the mountains. There are trade-offs, absolutely. Waiting on a vendor to fix a problem _for months_, while sending them hefty checks, is far inferior to waiting 3 hours on a Saturday for a fix, where the actual issue only effects new installations of a CLI tool used by developers, and can trivial be sidestepped. If anything, it's a chance to teach my developers about dep management! I'm positive my stack includes `is-promise` about 10 times. And I have no problem with that. If you upgrade deps (or don't) in any language, and don't have robust testing in place, the sysadmin in me hates you - I've seen it in everything from Go to PHP. There is no silver bullet except pragmatism!
- sosodev 6y ago
  There’s no silver bullet you’re absolutely right, but does that mean there isn’t room for improvement? Or that you shouldn’t try? Dropping all dependencies is extreme for sure but to argue against something as simple as vendoring is a bit odd.
  - erulabs 6y ago
    You’re correct - there is room for improvement. The “npx” tool is a easy place to start! And absolutely agreed dropping dependencies is extreme and vendoring not so much - but in my experience vendoring often means “don’t ever touch again until a bad security shows up”. I was being a little bit too snarky in my comment tho, absolutely :)
  - lmm 6y ago
    Vendoring causes more problems than it solves. There are plenty of things that could be improved about the node ecosystem, but a lot of the criticism isn't based on logic; there seems to be a large population on HN who just inherently hate large numbers of dependencies and will grasp for any excuse to justify that hate.
ahupp 6y ago
There's a neat tool called crater (https://github.com/rust-lang/crater https://github.com/rust-lang/crater) for Rust. It can run an experiment across every Rust package (or every popular one), so you can e.g see if some theoretically breaking compiler change actually hits anyone. Something like that could be interesting for node packages as well.
fourseventy 6y ago
pathetic ecosystem
gitgud 6y ago
Dependencies in almost any software system are fundamentally built on trust. You trust that minor version upgrades won't break the system, or that malicious code won't be introduced. But we're human... things break. This can happen in any ecosystem, but npm is particularly vulnerable because of it's huge dependency trees. Which is only possible due to the low overhead of creating, including and resolving packages. That's why npm has the "package-lock" file, which takes a snapshot of the entire dependency tree, allowing a truly reproducible build. Not using this is a risk.
arrty88 6y ago
Maybe it should be easier to do npm install latest-1
dstaley 6y ago
This is a prime example of where I think GitHub's acquisition of Dependabot and npm could really pay off. Imagine being able to publish a prerelease version of your library and run the CI tests of your consumers, all from within the GitHub interface. Dependabot already tracks compatibility between versions, so this would be a natural extension of that.
biglost 6y ago
A package just for: return !!obj && (typeof obj === 'object' || typeof obj === 'function') && typeof obj.then === 'function'; https://github.com/then/is-promise/blob/master/index.js https://github.com/then/is-promise/blob/master/index.js This is insane
hota_mazi 6y ago
Everywhere around the world, users of Maven Central facepalm.
adrianhel 6y ago
There should be a Promise.isThenable or Promise.is. Strictly speaking this library checks if a value is a thenable. With optional chaining I would however use this check: typeof x?.then === 'function' Or if I was code golfin: x?.then?.call The first case does not account for built in prototype extensions and the second has false positives with certain data structures. So the function in is-promise should be available as Promise.isThenable or Promise.is.
habosa 6y ago
I am one of the maintainers of a popular Node-based CLI (the firebase CLI). This type of thing has happened to us before. I think the real evil here is that by default npm does not encourage pinned dependency versions. If I npm install is-promise I'll get something like "^1.2.1" in my package.json not the exact "1.2.1". This means that the next time someone installs my CLI I don't know exactly what code they're getting (unless I shrinkwrap which is uncommon). In other stacks having your dependency versions float around is considered bad practice. If I want to go from depending on 1.2.1 to 1.2.2 there should be a commit in my history showing when I did it and that my CI still passed. I think we miss the forest for the trees when we get mad about Node devs taking small dependencies. If they had pinned their version it would have been fine.
- KMnO4 6y ago
  That’s still the fault of the package developer. “^1.2.1” means “any version with a public API compatible with 1.2.1”, or in other words “only minor versions”. The whole point of semantic versioning is to guarantee breaking changes are expressed through major versions. If you break your package’s compatibility and bump the version to 1.2.1 instead of 2.0.0 then people absolutely should be upset.
  - lukevp 6y ago
    Allowing any version drift of dependencies at all means that if you don’t check in and restore using the package lock file, you cannot have reproducible builds. The package lock files are themselves dependent on which package restore tool you are using (yarn vs npm vs ...) it’s also much too ambitious to believe that all packages in an ecosystem will properly implement semver. There may even be times where a change doesn’t appear to be breaking to the maintainer but is in actuality. For example, suppose a UI library has a css class called card-invalid-data and wanted to rename to card-data-invalid. This is an internal change since it is their own css, but could break a library that overrode this style or depended on this class. I would consider this a minor version but it could still cause a regression for someone.
    - 6y ago
tablethnuser 6y ago
This seems like an issue with semver. Its idealism is not compatible with actual human behavior. The package devs clearly violated semver guidelines and npm puts a lot of faith in individual packages to take semver seriously. By default it opts every user into semver. If you need semver to be explained to you bottom up (lists of 42 things that require a major bump) then you don't get semver. All you have to do is think: will releasing this into a world full of "^1.0.0" break everyone's shit? This and left-pad are extreme examples. But any maintainer with a package.json who tries to do right by `npm audit` knows that there is an endless parade of suffering at the hands of semver misuse. Most of it doesn't make the news.
keithnoizu 6y ago
meanwhile I can regularly override even major release versions of dependencies in elixir with out breaking changes. dependency fickleness has always been a huge issue for me when working with node.
escot 6y ago
Anyone know of a way that library maintainers can automatically test if changes like this will break consumers?
nerdycap007 6y ago
I had an issue while running any command of vue-cli.. and then I even created an issue for it thinking that it might be a bug in the Vue CLI v4.3.1 But I think the truth has shown itself!

599 points by tessela 6y ago

TechBro8615 6y ago

The package referred to in the clickbait title is `is-promise`

ajross 6y ago
I don't know how "clickbait" that title can be when it is, in fact, longer than the line of code in question: declare function isPromise<T, S>(obj: Promise<T> | S): obj is Promise<T>; This is, indeed, the only line of exported code in the entire package. I genuinely don't understand the NPM world.
- jakear 6y ago
  That's just the type definition. Think of it like the .h if you're into that sort of thing.
- redmorphium 6y ago
  Me neither. I can't wait for Deno 1.0 next month. https://deno.land/ https://deno.land/
  - stickac 6y ago
    How exactly will the new runtime fix the habit of Javascript developers to pull-in millions of dependencies?
  - freeqaz 6y ago
    What is this exactly? The website is a bit unclear.
    - jpangs88 6y ago
      I was wrong about what this was I have edited this comment
      - eropple 6y ago
        Why would a Rust wrapper around the C++ project that is V8, which implements a garbage-collected programming language and environment, "use less ram" just by virtue of some parts of it being written in Rust?
        deleted 6y ago
        [deleted]
    - frank2 6y ago
      Deno is much like node (uses the V8 engine, does not require a browser) and was created by the man who created node.
  - jpangs88 6y ago
    Makes me look forward to this more https://romejs.dev/ https://romejs.dev/ since one of the ideas is that it will have no third party dependencies...
- hn_throwaway_99 6y ago
  > I genuinely don't understand the NPM world. You're right, you don't. What you posted is just the function declaration, not the implementation.
  - deleted 6y ago
    [deleted]
- hughes 6y ago
  I think it reflects how the evolution of the JS ecosystem strongly resembles natural evolution. This package is now a vestigial organ, but there was a time when it served a useful purpose. Other packages formed connective tissue to this package, and since those package may still be useful, this one has stuck around.
- deleted 6y ago
  [deleted]
- svnpenn 6y ago
  NPM is the answer to the question: what would happen if everyone refused to use any idioms ever, and instead replace them all with packages? God help you, if you import a JavaScript (or Rust) package today. Lest you fall in a gaping chasm of endless cascading dependencies.
  - linkdd 6y ago
    It's not NPM's fault, it's developer's fault. I would never in my right mind publish a one-line package, Python, Javascript, whatever. And I would never add a one line package as dependency
Lammy 6y ago
Does the package name need to be in the title if it's already the URL? :)
- deleted 6y ago
  [deleted]
tzs 6y ago
How would you rewrite the title to not be clickbait?
- detaro 6y ago
  "1-line package "is-promise" broke `NPM create-react-app`" ?
- TechBro8615 6y ago
  I would include the name of the package.
dang 6y ago
The title doesn't strike me as clickbait. The significant thing is what happened.
- TechBro8615 6y ago
  Personally as a JS dev, the significant thing is which package it was. These stories happen all the time, so when I see them I’d rather know which package it is at a glance so I know if I’m affected.
  - capableweb 6y ago
    Fun thing with building applications overusing npm is that you usually don't know exactly what packages you have. Not until you check for the specific package, so you probably don't "know at a glance" if you're affected or not.
    - TechBro8615 6y ago
      Hah, true. I got bit by one of these two days ago where the offending package was trying to install node itself (wtf?). It was two levels deep of `yarn why` before I figured out the issue. Fortunately I've been around long enough that the first thing I did was check the package for github issues... sure enough, found a 5 hour old issue with a bunch of people complaining of failing builds. If I hadn't searched first, I probably would have banged my head for another couple hours...

0xff00ffee 6y ago

This is why regression suites are important. EDIT: I wasn't dissing the developers. They have regression, this was just an accident. I was stating it is important. My bad (too late to delete).

SSchick 6y ago
The package does have CI setup, however the test matrix does not cover the latest node versions (which are the ones that are affected). See https://github.com/then/is-promise/blob/master/.travis.yml https://github.com/then/is-promise/blob/master/.travis.yml (missing v11, v12, v13, v14)
- RyJones 6y ago
  And CI is failing[0]. [0]: https://travis-ci.org/github/then/is-promise/builds https://travis-ci.org/github/then/is-promise/builds
  - SSchick 6y ago
    The failing CI here is unrelated to the issue but it's still pretty bad a release was made with failing CI.
    - jessaustin 6y ago
      It was a five-year release (followed quickly by a 3.5-hour release and a sub-minute release) [0], so they may not have wanted to dig into CI. [0] https://github.com/then/is-promise/releases https://github.com/then/is-promise/releases
seibelj 6y ago
Install any moderately complex nodejs lib or app and it will throw tons of warnings, ignored errors, and security issue alerts. As you should with any app running in production, lock down everything and watch network traffic because there are innumerable backdoors in the JavaScript ecosystem.

SSchick 6y ago

Probably also broke eslint too since `is-promise` is also a sub-dependency of that as well. This is much less of an issue when using a lockfile, at least for existing packages/projects.

esaym 6y ago

You had one job...

chvid 6y ago

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

artursapek 6y ago
My prior decision to never work with JavaScript again has just grown firmer.
- mothsonasloth 6y ago
  I second this, JavaScript Devs are near the bottom of the food chain, just above VB Devs. Myself as a Java developer is middle of the pyramid. The apex predators are embedded developers, followed by c Devs then game Devs.
  - smt88 6y ago
    It's not useful, interesting, or accurate to stratify people this way. You have no idea what someone's intelligence level or background is based on their usage of JS or C. I loathe JS, but one of the best devs I know likes it. People's mileage varies. For me personally, there's much more money in easy React products than making games. I'm not a great dev, but I'd be doing this same work even if I were.
  - TechBro8615 6y ago
    The “food chain?” What do you mean by that?
    - deleted 6y ago
      [deleted]
  - gombosg 6y ago
    I sincerely hope you're being sarcastic here.

ng12 6y ago

Looks like it broke @angular/cli too.

Noumenon72 6y ago
Who does this affect? I just did npx @angular/cli new hello-world-project and that worked. I have remote Angular training on Monday and didn't want to do a global install.
- ng12 6y ago
  It's already been patched with version 2.2.1.

tholman 6y ago

Hmm, I had some problems with a nested `is-object` dependency when updating some deps last week, I wonder if it’s related.

sergiotapia 6y ago

The javascript ecosystem is a total house of cards, "webshit" as they call it in some other sites, rings true more and more.

_greim_ 6y ago
Agreed. Libraries and tools often don't work in a straightforward manner. Lots of tools reach below the surface and do their own tampering and monkey-patching of the runtime, module system or environment. Layer upon layer gets deposited over time. It's like doing construction on topsoil riddled with unmarked gas, water, and electrical lines.

brown9-2 6y ago

There is something aggravating about the first comment in an issue like this posted minutes after the issue was created to say “is this fixed yet?”

deleted 6y ago
[deleted]
ehsankia 6y ago
The worst part is that it was posted 10 minute later... I understand bumping a year old issue, but cmon give it a few minutes at least.
- luckylion 6y ago
  It was posted after chore: fix is-promise, they may have not realized that it's just some random pingback that github shows there, and not a message that somebody has committed a fix.

gav 6y ago

Digging into the reason behind breakage, the change is this one: https://github.com/then/is-promise/commit/feb90a40501c8ef69b0c65bdf1eb703182214407#diff-b9cfc7f2cdf78a7f4b91a753d10865a2 https://github.com/then/is-promise/commit/feb90a40501c8ef69b... Which adds support for ES modules: https://medium.com/@nodejs/announcing-core-node-js-support-for-ecmascript-modules-c5d6dc29b663 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/3b3ea4150d9a0788ed467d0c05a7e67f5070e32a https://github.com/then/is-promise/pull/15/commits/3b3ea4150...

searchableguy 6y ago
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.
- ng12 6y ago
  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.
- jrochkind1 6y ago
  What's "yarn zero installs"? Googling did not do it for me.
  - _630w 6y ago
    Instead of node_modules containing source code of the packages, yarn generates a pnp.js file which contains a map linking a package name and version to a location on the disk, and another map linking a package name and version to its set of dependencies. All the installed packages are stored in zip form in .yarn/cache folder to provide a reproducible build whenever you install a package from anywhere. You can commit them to version control. Unlike node_modules, they are much more smaller in size due to compression. You will have offline, fully reproducible builds which you can test using a CI before deployment or pushing code to repository https://yarnpkg.com/features/zero-installs https://yarnpkg.com/features/zero-installs

andrew_ 6y ago

It's downloaded 11 million times a week. This touches a good majority of the Node ecosystem, so there's going to be quite a lot that doesn't work until this is remedied. And I'm not sure that package-lock.json is going to save folks here because it was a minor version update. https://www.npmjs.com/package/is-promise https://www.npmjs.com/package/is-promise

remram 6y ago
Doesn't the lock file lock exact versions?
roonyh 6y ago
package-locks lock down exact versions. Otherwise there's no point to them.

zulgan 6y ago

Chill with the js hate, this happens everywhere. Maybe not to this extend, but if X (where X is whatever you are thinking about) had similar amount of people using it (especially junior people) this would happen there as well.

ddevault 6y ago
No, this does not happen everywhere. Show me this happening in Debian.
- RussianCow 6y ago
  You can't use the very latest version of any software in Debian at all without adding a custom repository, at which point you have the same issue. So the comparison is not apples to apples.
  - quantummkv 6y ago
    How about a rolling release like openSUSE tumbleweed then? I have been using it for years, I generally update once a week and I have never broken my system due to an update. Never.
  - ddevault 6y ago
    You can use Debian Unstable, or maybe just use stable and reliable dependencies so that your software is also stable and reliable. That would require putting in some effort, though, and we can't be having that, can we?
    - RussianCow 6y ago
      You can do that with NPM if you pin your dependencies to exact versions, which is the same solution that you would use for any other package manager, and basically what Debian and other Linux distros do for you. I don't know why you think this problem is somehow unique to NPM or the JavaScript ecosystem.

montroser 6y ago

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 pinning your dependency versions, rather that package maintainers trying to make it all happen.

tgv 6y ago
> pin your dependency versions And then to see "npm detected 97393 problems" or whatever the message exactly is.
- acdha 6y ago
  That’s good: it’s easy to update and it means you do it in a controlled manner rather than the next time something deploys.
- montroser 6y ago
  You don't need to pin them forevermore -- just when you don't want everything to break unexpectedly :). When you want to upgrade your dependencies, then go ahead and do that, on your own schedule, with time and space to fix whatever issues come up, update your tests, QA, etc.
mikewhy 6y ago
> pin your dependency versions for projects running in production Works for existing apps, but people using create-react-app and angular CLI can't even start a new project.
- staticassertion 6y ago
  I don't know much about those projects, but why did this break them? Are they not pinning versions?

0x7265616374 6y ago

You can thank https://twitter.com/ForbesLindesay https://twitter.com/ForbesLindesay for breaking Node today.

eropple 6y ago
This is nothing but an attempt at brigading. Get out of here with this.

jackewiehose 6y ago

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 going to fix that?

krapp 6y ago
>Is someone going to fix that? Probably not. There is too much code in the wild, and NPM owns the entire JS ecosystem, and there has been too much investment in that ecosystem and its culture at this point for a change in course to be feasible. The JS universe is stuck with this for the foreseeable future.
- jackewiehose 6y ago
  Does it need much to change? I didn't mean to fix NPM. The problem is the non-existing standard-library. Just create one that everybody will use and everybody could cut their dependencies by thousands.
  - krapp 6y ago
    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 a problem after the ecosystem got taken over by a set of programming paradigms that make no sense for the language. Yes, in my mind you'd have to change everything from the ground up, starting with no longer using javascript outside of the browser.
    - jackewiehose 6y ago

sneak 6y ago

I hope that more packaging systems take the go modules approach and cryptographically and immutably identify their dependencies at time of addition to the project. This sort of breakage shouldn’t be possible.

dnautics 6y ago
I'm sorry if you were unaware, but they absolutely do that, and were doing that long before go was.
- sneak 6y ago
  I am aware of package lockfiles. If deps are immutable, then nothing anyone does in any other package (short of having the package repository take the code down) should be able to break your future builds. If that were true, TFA would not be news.
  - dnautics 6y ago
    I'm not a node expert but i believe the problem is that most people auto-update their node dependencies (I know I do, but I only have to do it rather rarely, since I don't primarily use node), because there are just so often minor security regressions that need to be fixed.
  - n_e 6y ago
    > If deps are immutable, then nothing anyone does in any other package (short of having the package repository take the code down) should be able to break your future builds. They are. You're only affected if you don't use a package-lock.json or start a new project (which will pull the latest versions of the dependencies).
jen20 6y ago
This kind of breakage is perfectly possible in Go also - though the most common equivalent of "left-pad broke my project" for many Go developers is "X changed the case of their GitHub username and now all my import paths are broken".

odensc 6y ago

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.

thawkins 6y ago
So you would exchange security for stability, if you use package pinning then you will end up with fosilized packages in your product, which will have all maner of security issues that have alresdy been fixed.
- flukus 6y ago
  If a package doesn't provide a stable branch that will receive security updates then it's not mature enough to be used anyway. That's the sensible middle ground between bleeding edge and security, unfortunately most packages/projects aren't mature enough to provide this. There's a reason companies stick with old COBOL solutions, modern alternatives simply aren't stable enough.
- deleted 6y ago
  [deleted]
- linkgoron 6y ago
  You can always use something like dependabot, which should help you quickly upgrade versions and also protect you from breaking your build.
- rhizome 6y ago
  I get notifications to update my Rails apps from GitHub as a matter of course when there's a CVE in my dependencies. Does this kind of thing not exist/is impractical for JS?
  - hobofan 6y ago
    From my experience of getting ~30 of those notifications per week for a handful of JS repos, I can very much assure you that it does exist.

ConcernedCoder 6y ago

mrw you're using a package to do a type-check: return !!obj && (typeof obj === 'object' || typeof obj === 'function') && typeof obj.then === 'function'

deleted 6y ago

[deleted]

jbverschoor 6y ago

Is this news? Happened so many times before. NPM is broken. Yarn 2.0 is never gonna take off. These problems have been fixed long before. Waste of life.

kingbirdy 6y ago

The the broken package just released a fix: https://github.com/then/is-promise/releases/tag/2.2.1 https://github.com/then/is-promise/releases/tag/2.2.1

russtrotter 6y ago

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".

throwanem 6y ago
There are a lot of idioms. A very common one, I think the current default, is to pin only the major version in the dependency list, and also to lock exact versions in an installer-generated lockfile following a successful install. If you find a locked version breaks your code, you adjust your dependency list, nuke the lockfile, and let a reinstall build it again. The idea is that pinning major versions lets you get non-breaking improvements from package authors who use semver properly, and pinning exact known-good versions lets you avoid surprises in your CI builds. It works pretty well when you start from a known good state and vet your dependencies reasonably well. The trouble here seems to be largely that CRA is designed, among other purposes, to serve people just getting into the ecosystem of which it's a part, and those people are unlikely to be familiar enough with the details I've described to be able to effectively respond. The comparison with left-pad is easy, but this isn't at all on the same scale. It's a bad day for newbies and a minor annoyance for experienced hands. And, of course, cause for endless spicy takes about how Javascript is awful, but such things are as inevitable as the sunrise and merit about the same level of interest.
n_e 6y ago
The "idiomatic way" is to use a package-lock.json, which keeps the dependencies (and transitive dependencies) at the exact version specified unless you decide to upgrade them.
diggan 6y ago
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.

throwanem 6y ago

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 instanceof Promise isn't enough of a test for things whose provenance you don't control. Of course, such a situation can't last forever. If the idea is good enough, eventually someone will come along and, as Linux did to Unix, kill the parent and hollow out its corpse for a puppet, leaving the vestiges of the former ecosystem to carve out whatever insignificant niche they can. Now the major locus of incompatibility in the "Unix" world is in the differences between various distributions, and what of that isn't solved by distro packagers will be finally put to rest when systemd-packaged ships in 2024 amid a flurry of hot takes about the dangers of monoculture. Bringing it back at last to the subject at hand, 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. As a former-life devotee of Stack Overflow, I of course applaud this plan, and wish them all the luck they're certainly going to need. The impetus behind "lol javascript trash amirite" channer takes today is exactly that behind the UNIX-Haters Handbook of yore. I have a printed copy of that, and it's still a fun occasional read. But those who enjoy "javascript trash lol" may do well to remember the Handbook authors' stated goal of burying worse-is-better Unix in favor of the even then senescent right-thing also-rans they favored, and to reflect on how well that played out for them.

morelisp 6y ago
This analogy doesn't hold up at all. The UHH is a fun read, yes, but the biggest real-world problem with the Unix Wars was cross-compatibility. Your Sun code didn't run on Irix didn't run on BSD and god help you if a customer wanted Xenix. OK, you can draw some parallel here between React vs. Vue vs. Zeit vs. whatever. But there was also the possibility, for non-software businesses, to pick a platform and stick to it. You run Sun, buy Sun machines, etc. That it was "Unix" didn't matter except to the software business selling you stuff, or what kind of timelines your in-house developers gave. There is no equivalent in the JS world. If you pick React, you're not getting hurt because Vue and React are incompatible, you're getting hurt because the React shit breaks and churns. Every JavaScript community and subcommunity has the same problem, they keep punching themselves in the face, for reasons entirely unrelated to what their "competitors" are doing. Part of this is because the substrate itself is not good at all (way worse than Unix), part is community norms, and part is the piles of VC money that caused people to hop jobs and start greenfield projects every three months for 10 years rather than face any consequences of technical decisions. Whatever eventually hollows out the mess of JS tech will be whatever figures out how to offer a stable developer experience across multiple years without ossifying. (And it can't also happen until the free money is gone, which maybe has finally come.)

bambataa 6y ago

create-react-app was broken a couple of weeks ago when I tried to use the Typescript template. Some dependency in Jest had been changed to require a version of Typescript that had only been out for a few weeks, breaking everything (including create-react-app) that hadn't updated to the latest tsc. What an ecosystem.

deleted 6y ago

[deleted]

CapriciousCptl 6y ago

Someone somewhere is going to organize a series of JS packages with the continuity of a standard library and full of verification and tests. Sane versioning, consistent interfaces and so on. The npm ecosystem isn't bad it's just unwieldy successful.

rubyn00bie 6y ago

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, that's the obvious, easy way of doing this" it's not a package, it's a pattern. I can promise you, this was only ever added to packages because people wrongly assumed because since it's about "promises" (spooooky) it must be complex and worthy of packaging. As someone who doesn't do front-end work regularly, but also sank about 3 consecutive weeks (~6-8 hours/day) in the last year into understanding generators, yielding, and promises... I can tell you, the actually scary part about all of this, is pretty much no one just reads the fucking docs or the code they're adding. Moral of the story, especially in the browser: the reward of reading the code before adding it is enormous, you'd be surprised how often the thing you want is just a simple pattern. Taking that pattern and applying it to your specific use case, instead of imposing that pattern on your use case will give you giant wins.... Learn the patterns and you're set for life.

xyst 6y ago
tbh, it's something that should be included in a standard library (not a third party package or dependency)
- globular-toast 6y ago
  Or just copy and paste it into your project. Using a dependency for one line is beyond ridiculous.
ganstyles 6y ago
I wish I had as much time as you. Looking through the source code of the millions and millions of lines of code that get packaged with any modern application before you add things to your projects sounds daunting!
bdcravens 6y ago
create-react-app contains over 1000 packages. How long would it take to review all of those?

xyst 6y ago

Now I understand the reasoning behind the Golang suggestion to commit the /vendor directory.

choward 6y ago

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

jhanschoo 6y ago
For compatibility with old versions of JS without Promise, when libraries used thenables or a promise library.
franciscop 6y ago
Somehow convoluted, but if you wrap in a promise like this then you make it async (similar to setTimeout(fn, 0)), so in some situations you might want to keep the non-promised code as non-promise: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... (red is async, blue is sync)
turnipla 6y ago
This is not a library. Stop thinking of it as a library. It's a building block, a module. > why a library like this is even necessary? Do you know how to determine whether something is a Promise? Wrong. Also the first few StackOverflow answers are wrong or incomplete. You know what's better? Using the same library 3.4 million repos depend on, that is tested and won't break if you use a package-lock. > Can't you just wrap everything and treat it like a promise? Maybe. Maybe not. Treating everything as a Promise means you have to make your function asynchronous even if not necessary.

c-smile 6y ago

Weinberg's Law: If Builders Built Buildings the Way Programmers Wrote Programs, Then the First Woodpecker That Came Along Would Destroy Civilization.

blast 6y ago
That's the soft in software.
Ididntdothis 6y ago
This sounds very clever but the nature of software development is quite different from building buildings. The rate of innovation is by magnitudes higher. And as opposed to buildings software can tolerate a certain amount of failure.
- rhizome 6y ago
  "Pfft. Chickens don't even know what a road is!"
sipos 6y ago
Why are So Many of the Words in This Comment Capitalised? Is it a Title of Something?

janpot 6y ago

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.

xyst 6y ago
how about "single function" instead?
turnipla 6y ago
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.

jrockway 6y ago

A little copying is better than a little dependency.

unwoundmouse 6y ago

nvm

searchableguy 6y ago
Read the linked post.
- unwoundmouse 6y ago
  FUCK I thought the linked article described the situation
  - tomphoolery 6y ago
    way to read the article before commenting
droidist2 6y ago
Isn't this the story of leftpad?

antibland 6y ago

One reason why we may have one line packages is the demand FAANG places on applicants. On three job screens from three different companies, I was asked, "Which npm packages have you created that we'd know about?" For many who are hell-bent on entering these companies, yet have no known packages under their belt, they very well might fire off a one line package that actually gets some downloads, to be better "prepared" when screened.

dgellow 6y ago

As always: vendor your dependencies.

ojr 6y ago
vendoring my dependencies wouldn't save me from a rare issue I had dealing with npm packages, for example I had a package that relied on an underlying api call to a machine learning cloud api, the api call became deprecated. Not writing code is the only sure way to have no bugs.
lpghatguy 6y ago
Using package-lock.json gives you the same effect.
turnipla 6y ago
Good luck vendoring node_modules. Why are these threads filled with people who know nothing about node? npm and yarn both have lockfiles for this purpose. Vendoring only bloats your repos.
- dgellow 6y ago
  > Why are these threads filled with people who know nothing about node? That’s a quite bad assumption from your part based on almost no information. I don’t know about the rest of the thread but I’m personally quite familiar with node. A lock file doesn’t fix the same issues vendoring does. The lock file gives you an explicit list of version used, vendoring save the exact copies of the dependency with the rest of your code. By vendoring anyone who is working on the project is using the exact same version of a dependency, AND you don’t have to care about an external provider (the registry being up, etc, that’s way easier for you CI too), AND you can review dependencies upgrade via git as if it was your code. Of course that’s a mess when the JavaScript ecosystem has an infinite amount of dependencies for a hello world.

worik 6y ago

Why NPM? I think that is the real question I do not see anybody asking. SO I will... Why NPM?? What is the point?

worik 6y ago
Right. No point at all. A waste of time and a yawning security hole

ashtonkem 6y ago

The fact that this has broken serverless for people is reinforcing my priors in a big way.

cryptoquick 6y ago

Does anyone know if there's a way to upgrade a dependency of a dependency of a dependency of a dependency of a dependency in my yarn.lock without actually editing the yarn.lock, and also, waiting for five packages to update their dependencies, especially if they're locked or specified by even one of the five in semver rules? For example: Running `yarn why is-promise` in a CRA app: `Hoisted from "react-scripts#react-dev-utils#inquirer#run-async#is-promise"` Currently, running a `yarn upgrade-interactive --latest` doesn't indicate there are any updates, so presumably, this is still a problem upstream. Also, if anyone's in a pinch right now, luckily enough, I made this yesterday, for an interview I had only a couple hours ago. I lucked out! But if anyone else might need it, maybe it'll help someone: https://github.com/cryptoquick/demo-cra-ts https://github.com/cryptoquick/demo-cra-ts Oh, and, uh, pardon the pun... :/

acemarke 6y ago
Per other comments in the thread, this is the primary use case for Yarn's "resolutions" feature: https://classic.yarnpkg.com/en/docs/selective-version-resolutions/ https://classic.yarnpkg.com/en/docs/selective-version-resolu...
- cryptoquick 6y ago
  Thanks! Tried, it seems to work! Repo updated, too. This seems to be what it does, for those curious: https://github.com/cryptoquick/demo-cra-ts/commit/5c84aa48e9409478a6b19e2f065fa99313d6b10f https://github.com/cryptoquick/demo-cra-ts/commit/5c84aa48e9...

erulabs 6y ago

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'd quit tech and move up into the mountains. There are trade-offs, absolutely. Waiting on a vendor to fix a problem _for months_, while sending them hefty checks, is far inferior to waiting 3 hours on a Saturday for a fix, where the actual issue only effects new installations of a CLI tool used by developers, and can trivial be sidestepped. If anything, it's a chance to teach my developers about dep management! I'm positive my stack includes `is-promise` about 10 times. And I have no problem with that. If you upgrade deps (or don't) in any language, and don't have robust testing in place, the sysadmin in me hates you - I've seen it in everything from Go to PHP. There is no silver bullet except pragmatism!

sosodev 6y ago
There’s no silver bullet you’re absolutely right, but does that mean there isn’t room for improvement? Or that you shouldn’t try? Dropping all dependencies is extreme for sure but to argue against something as simple as vendoring is a bit odd.
- erulabs 6y ago
  You’re correct - there is room for improvement. The “npx” tool is a easy place to start! And absolutely agreed dropping dependencies is extreme and vendoring not so much - but in my experience vendoring often means “don’t ever touch again until a bad security shows up”. I was being a little bit too snarky in my comment tho, absolutely :)
- lmm 6y ago
  Vendoring causes more problems than it solves. There are plenty of things that could be improved about the node ecosystem, but a lot of the criticism isn't based on logic; there seems to be a large population on HN who just inherently hate large numbers of dependencies and will grasp for any excuse to justify that hate.

ahupp 6y ago

There's a neat tool called crater (https://github.com/rust-lang/crater https://github.com/rust-lang/crater) for Rust. It can run an experiment across every Rust package (or every popular one), so you can e.g see if some theoretically breaking compiler change actually hits anyone. Something like that could be interesting for node packages as well.

fourseventy 6y ago

pathetic ecosystem

gitgud 6y ago

Dependencies in almost any software system are fundamentally built on trust. You trust that minor version upgrades won't break the system, or that malicious code won't be introduced. But we're human... things break. This can happen in any ecosystem, but npm is particularly vulnerable because of it's huge dependency trees. Which is only possible due to the low overhead of creating, including and resolving packages. That's why npm has the "package-lock" file, which takes a snapshot of the entire dependency tree, allowing a truly reproducible build. Not using this is a risk.

arrty88 6y ago

Maybe it should be easier to do npm install latest-1

dstaley 6y ago

This is a prime example of where I think GitHub's acquisition of Dependabot and npm could really pay off. Imagine being able to publish a prerelease version of your library and run the CI tests of your consumers, all from within the GitHub interface. Dependabot already tracks compatibility between versions, so this would be a natural extension of that.

biglost 6y ago

A package just for: return !!obj && (typeof obj === 'object' || typeof obj === 'function') && typeof obj.then === 'function'; https://github.com/then/is-promise/blob/master/index.js https://github.com/then/is-promise/blob/master/index.js This is insane

hota_mazi 6y ago

Everywhere around the world, users of Maven Central facepalm.

adrianhel 6y ago

There should be a Promise.isThenable or Promise.is. Strictly speaking this library checks if a value is a thenable. With optional chaining I would however use this check: typeof x?.then === 'function' Or if I was code golfin: x?.then?.call The first case does not account for built in prototype extensions and the second has false positives with certain data structures. So the function in is-promise should be available as Promise.isThenable or Promise.is.

habosa 6y ago

I am one of the maintainers of a popular Node-based CLI (the firebase CLI). This type of thing has happened to us before. I think the real evil here is that by default npm does not encourage pinned dependency versions. If I npm install is-promise I'll get something like "^1.2.1" in my package.json not the exact "1.2.1". This means that the next time someone installs my CLI I don't know exactly what code they're getting (unless I shrinkwrap which is uncommon). In other stacks having your dependency versions float around is considered bad practice. If I want to go from depending on 1.2.1 to 1.2.2 there should be a commit in my history showing when I did it and that my CI still passed. I think we miss the forest for the trees when we get mad about Node devs taking small dependencies. If they had pinned their version it would have been fine.

KMnO4 6y ago
That’s still the fault of the package developer. “^1.2.1” means “any version with a public API compatible with 1.2.1”, or in other words “only minor versions”. The whole point of semantic versioning is to guarantee breaking changes are expressed through major versions. If you break your package’s compatibility and bump the version to 1.2.1 instead of 2.0.0 then people absolutely should be upset.
- lukevp 6y ago
  Allowing any version drift of dependencies at all means that if you don’t check in and restore using the package lock file, you cannot have reproducible builds. The package lock files are themselves dependent on which package restore tool you are using (yarn vs npm vs ...) it’s also much too ambitious to believe that all packages in an ecosystem will properly implement semver. There may even be times where a change doesn’t appear to be breaking to the maintainer but is in actuality. For example, suppose a UI library has a css class called card-invalid-data and wanted to rename to card-data-invalid. This is an internal change since it is their own css, but could break a library that overrode this style or depended on this class. I would consider this a minor version but it could still cause a regression for someone.
  - 6y ago

tablethnuser 6y ago

This seems like an issue with semver. Its idealism is not compatible with actual human behavior. The package devs clearly violated semver guidelines and npm puts a lot of faith in individual packages to take semver seriously. By default it opts every user into semver. If you need semver to be explained to you bottom up (lists of 42 things that require a major bump) then you don't get semver. All you have to do is think: will releasing this into a world full of "^1.0.0" break everyone's shit? This and left-pad are extreme examples. But any maintainer with a package.json who tries to do right by `npm audit` knows that there is an endless parade of suffering at the hands of semver misuse. Most of it doesn't make the news.

keithnoizu 6y ago

meanwhile I can regularly override even major release versions of dependencies in elixir with out breaking changes. dependency fickleness has always been a huge issue for me when working with node.

escot 6y ago

Anyone know of a way that library maintainers can automatically test if changes like this will break consumers?

nerdycap007 6y ago

I had an issue while running any command of vue-cli.. and then I even created an issue for it thinking that it might be a bug in the Vue CLI v4.3.1 But I think the truth has shown itself!