A one-line package broke `npm create-react-app`(github.com) |
A one-line package broke `npm create-react-app`(github.com) |
return !!obj && (typeof obj === 'object' || typeof obj === 'function') && typeof obj.then === 'function'
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.
npx @angular/cli new hello-world-projectIf 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.
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.
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.
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.
Why NPM?? What is the point?
No point at all.
A waste of time and a yawning security hole
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.
declare function isPromise<T, S>(obj: Promise<T> | S): obj is Promise<T>;
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.
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).
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.
You and everyone here are not as clever as you think you are. This is why people prefer known-good implementations. The maintainer here did a bad release, big fucking deal.
As a comparison, Django, a large Python web framework, has only three dependencies (pytz, sqlparse, and asgiref), which don't have dependencies themselves
That's not a criticism of NPM, just the way it's being used today.
i made my comment more as a joke, shit happens everywhere, and as i said maybe not to this extend.
God help you, if you import a JavaScript (or Rust) package today. Lest you fall in a gaping chasm of endless cascading dependencies.
See https://github.com/then/is-promise/blob/master/.travis.yml (missing v11, v12, v13, v14)
Of course, you can always lock your build to exact versions of your dependencies (lock files in NPM used to be a complete cluster, in my opinion they are less of a cluster now - you can pretty much do everything you want with them but there are some gotchas that make it easy to shoot yourself in the foot). The issue is that when you run 'npm install', it will pull the latest semver-compatible versions of your dependencies.
So for everyone decrying how this is a bad example of NPM and the javascript ecosystem, I really think the opposite is true. Yes, it broke a lot of upstream dependencies, but importantly only for new builds of those items, and furthermore it was found almost immediately.
Also, of course, you can specify exact versions of your dependencies - you don't have to rely on semver. That means, though, that you need to be more vigilant about pulling in bug fixed and security fixes, and most people take the tradeoff that they are comfortable pulling in patch or minor versions, but using lock files once they have a build they have verified.
And the system under test shouldn't even compile for the tests to run either. So it isn't so much the regression suite saving you so much as it is just acting as the client of first resort.
> innumerable backdoors in the JavaScript ecosystem.
Same goes for Python and CPAN. Any "click here for fancy module" installer has this problem.
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).
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
Writing JavaScript on Debian is practically impossible without sidestepping the package manager in some way. In a lot of cases, the hacks you have to do to run up-to-date software on a distro like Debian decrease reliability significantly.
Open up any serious Python project and you'll find significant dependencies. Math, graphics, IO, stats, ML... anything you really want to do requires dependencies. In fact, one of my biggest issues with Python is the cross-platform incompatibility of many packages which makes it a terrible choice for my deployment. (Even worse if the project has Cython components!)
I often end up having to scour github for forked pywheels that aren't vetted. Which are then cloned ad infinitum.
Its a tradeoff between extensibility and open source / free software, and robustness.
Graphics -> Python comes with included Tkinter, and others are also one include away.
Stats -> Scipy does a lot of the stuff. There is a built in package for stats. Again, no stats package has 100 dependencies, and node doesn't even have anything with even 1/10th of the features
ML -> I mean node has nothing here, nothing, while pytorch has total of six dependencies. In node, left pad might have these many.
Python doesn't need left pad, isNumber, isInteger, isOdd, isPromise , take your pic.
> In fact, one of my biggest issues with Python is the cross-platform incompatibility of many packages which makes it a terrible choice for my deployment. (Even worse if the project has Cython components!)
But python has high performance libraries written in C, can you even use node for any of the cases where python has platform compat issues?
It is a tradeoff, and there is no comparison. Python needs far far less dependencies than node. e.g, Flask has 2 total dependencies, express has 48 direct dependencies, and even then flask comes out ahead on features, so much so that you would need many more packages to do the same stuff with express.
I’ve seen reports of people using a go library that gets a minor update and breaks their app, at which point they become SOL as go always installs the lad test version. I myself have been working in python projects where the dockerfile simply says “pip install blah” and I get different deps than the working version. No clue why anyone would be okay with working like that.
As a stretch target: it's a bad idea to create demons out of an assortment of posts you randomly saw on HN. This site gets 3M posts a year. You can find basically anything in there.
https://news.ycombinator.com/item?id=22098687
What happens is that we each have pre-existing images that bug us (e.g. for example, people who overrate their own genius) and as we move around in the statistical cloud, random bits of whatever we run into stick to the pre-existing image and give it form. Poof, you have a demon—but actually it just became visible. Readers with other images see other demons and arrive at other generalizations. It's not good discussion because it's really about one thing but we make it about another, and comments that are skewed in that way limit their own interestingness. (I definitely don't mean to pick on you personally. We all do this.)
It's not a failure of the language. Javascript has comparison operators like every other language, it's entirely possible to determine if a number is greater than or less than zero without importing a third-party package.
What it is is a failure of modern JS development culture, because apparently it's anathema to even write a simple expression on your own rather than import a dependency tree of arbitrary depth and complexity and call a function that does the same thing.
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. :-)
The issue I’ve seen is:
https://github.com/go-yaml/yaml/issues/558
> Please do follow semver as it's a nightmare for us to manage particularly using go module (you can't stick to a particular version).
And of course everybody’s idea of a breaking change is different, so this idea that you can’t install a particular version seems unworkable.
Which adds support for ES modules: https://medium.com/@nodejs/announcing-core-node-js-support-f...
However the exports syntax requires a relative url, e.g. ‘./index.mjs’ not ‘index.mjs’. The fix is here: https://github.com/then/is-promise/pull/15/commits/3b3ea4150...
Not that long, but my issue with this release snafu is that:
- the build didn't pass CI in the first place
- the CI config wasn't updated to reflect the most recent LTS release of node
- the update happened directly to master (although that's to how the maintainer wants to run their repo. it's been my experience that it's much easier to revert a squashed PR than most other options)
- it took two patch versions to revert (where it may have only taken one if the author could have pressed "undo" in the PR)
Another way is to pin down the specific versions without ~ or ^ in the package.json so your updates don't break stuff.
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.
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!
function isPromise(obj) {
return !!obj && (typeof obj === 'object' || typeof obj === 'function') && typeof obj.then === 'function';
}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.
Unless you mean Create React App should pin all of their (transitive) dependencies and release new versions multiple times a day with one of those dependencies updated.
There's a reason companies stick with old COBOL solutions, modern alternatives simply aren't stable enough.
Is someone going to fix that?
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.
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> 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.
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
(red is async, blue is sync)
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.
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.
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.
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.
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
Oh, and, uh, pardon the pun... :/
https://classic.yarnpkg.com/en/docs/selective-version-resolu...
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.
return !!obj && (typeof obj === 'object' || typeof obj === 'function') && typeof obj.then === 'function';
https://github.com/then/is-promise/blob/master/index.js
This is insane
This is much less of an issue when using a lockfile, at least for existing packages/projects.
With optional chaining I would however use this check:
typeof x?.then === 'function'
x?.then?.call
So the function in is-promise should be available as Promise.isThenable or Promise.is.
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.)
I agree that VC money is ultimately poison to the ecosystem and the industry, but that's a larger problem, and I could even argue that it's one which wouldn't affect JS at all if JS weren't fundamentally a good tool.
(To your edit: granted, and React, maybe and imo ideally plus Typescript, looks best situated to be on top when the whole thing shakes out, which I agree may be very soon. The framework-a-week style of a lot of JS devs does indeed seem hard to sustain outside an environment with ample free money floating around to waste, and React is both easy for an experienced dev to start with and supported by a strong ecosystem. Yes, led by Facebook, which I hate, but if we're going to end up with one de facto standard for the next ten years or so, TS/React looks less worse than all the other players at hand right now.)
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
POSIX is a set of IEEE standards that have been around in one form or another since the 80s, maybe JavaScript could follow Unix's path there.
Vanilla -> jQuery -> Angular.js -> Angular 2+, React pre-Redux existence -> modern React -> Vue (and hobby apps in Svelte + bunch of random stuff: Mithril, Hyperapp, etc)
I have something to say on the topic of:
> "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."
I find the fact that front-end has a fragmented ecosystem due to different frameworks completely absurd. We have Webcomponents, which are framework-agnostic and will run in vanilla JS/HTML and nobody bothers to use them.
Most frameworks support compiling components to Webcomponents out-of-the-box (React excepted, big surprise).
https://angular.io/guide/elements
https://cli.vuejs.org/guide/build-targets.html#web-component
https://svelte.dev/docs#Custom_element_API
If you are the author of a major UI component (or library of components), why would you purposefully choose to restrict your package to your framework's ecosystem. The amount of work it takes to publish a component that works in a static index.html page with your UI component loaded through a <script> tag is trivial for most frameworks.
I can't tell people how to live their lives, and not to be a choosy beggar, but if you build great tooling, don't you want as many people to be able to use it as possible?
Frameworks don't have to be a limiting factor, we have a spec for agnostic UI components that are interoperable, just nobody bothers to use them and it's infuriating.
You shouldn't have to hope that the person who built the best "Component for X" did it your framework-of-choice (which will probably not be around in 2-3 years anyways, or have changed so much it doesn't run anymore unless updated)
---
Footnote: The Ionic team built a framework for the singular purpose of making framework-agnostic UI elements that work with everything, and it's actually pretty cool. It's primarily used for design systems in larger organizations and cross-framework components. They list Apple, Microsoft, and Amazon as some of the people using it in production:
Deno always sounded more "like the Plan 9 of Javascript" personally to be honest. It seems to be better (yay for built-in TypeScript support! Though I have my reservations about the permission management, but that's another discussion) but perhaps not better enough (at least just yet) to significantly gain traction.
This, exactly this. Young me thought this was a point of the whole thingy we call Internet.
And exactly that is what I like about QML from Qt. Just point to a file and that's it.
I really like Deno for this reason. Importing modules via URL is such a good idea, and apparently it even works in modern browsers with `<script type="module">`. We finally have a "one true way" to manage packages in JavaScript, no matter where it's being executed, without a centralized package repository to boot.
So I'm not sure how much everything-used-to-be-great-nostalgia is justified here.
Any package and package manager has hot points:
- no standards, api connection issues (different programming styles and connection overhead)
- minor version issues (just this 1 hour bug 0-day)
- major sdk issues (iOS deprecate OpenGL)
- source package difference (Ubuntu/CentOS/QubesOS need a different magic for use same packages)
- overhead by default everywhere that produce multiple issues
Sadly, I dream of doing this very thing every day. I'm at that notch on the thermometer just before "burned out". I love creating a working app from scratch. However, I'm so sick of today's tech. The app stores are full of useless apps that look like the majority of other apps whose sole purpose is to gather the user's personal data for monetizing. The web is also broken with other variations of constant tracking. I'm of an age where I remember time before the internet, so I'm not as addicted as younger people.
Making upstream changes indeed would be very, very hard. But I never have to make upstream changes because they’ve spent quite a large amount of effort on stability.
Pragmatism - do programming to solve real life problems rather than create a broken ecosystems which requires constant changes (and learning just to be on top of them) to fix a bad design
I think the snark is obscuring the point of this comment.
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 saying "Anything with a .then is a promise' or other different ways of testing it. The code being convoluted shows that.
Should this problem be solved elsewhere? Sure, again, JavaScript is bad and no one's on the other side of that argument, but it's what we have. Is "just copy paste a wrong answer from SO and end up with 50 different functions in your codebase to check something" like other languages that make package management hard so much better ? I don't think so.
At work, our big webapp depended at some point indirectly on "isobject" "isobj" and "is-object", which were all one liners (some of them even had dependencies themselves!!). Please let's all just depend on lodash and it will actually eventually reduce space and bandwith usage.
const isFalsy = require("is-falsy");
const isObject = require("is-object");
const isFunction = require( "is-function" );
const hasThen = require( "has-then" );
function isPromise(obj) {
return !isFalsy(obj) && ( isObject(obj) || isFunction(obj) ) && hasThen( obj );
}
I think this would be the solution. I feel like a lot of the NPM transitive dependency explosion just comes from the fact that JavaScript is a language with a ton of warts and a lack of solid built-ins compared to e.g. Python. Python also has packages and dependencies, but the full list of dependencies used by a REST service I run in production (including a web framework and ORM) is a million times smaller than any package-lock.json I've seen.
x instanceof Promise
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 place), but then you want to check if the argument is a Promise, sure with `instanceof` the compiler knows that you are doing, otherwise not.
Also, look at the repo, a ton of files for a 1 line function? Really? You take less time to write that function yourself than to include that library. But you shouldn't have to write that function in the first place.
One-liners without dependencies like this should live as a function in a utility file. If justification is needed, there should be a comment with a link to this package's repo.
At the very least, W3, or Mozilla Foundation, or something with some kind of quasi-authority should release a "JS STD" package that contains a whole bunch of helper functions like this. Or maybe a "JS Extras" package, and as function usage is tracked across the eco-system, the most popular/important stuff is considered for addition into the JS standard itself.
Having hundreds of packages that each contain one line functions, simply means that there are hundreds of vectors by which large projects can break. And those can in turn break other projects, etc.
The reason, cynically, that these all exist as separate packages, is because the person who started this fiasco wanted to put a high a download count as possible on his resume for packages he maintains. Splitting everything up into multiple packages means extra-cred for doing OSS work. Completely stupid, and I'm annoyed nobody has stepped up with a replacement for all this yet.
In properly designed languages, values have either a known concrete type, or the interfaces that they have to support are listed, and the compiler checks them.
Even in JavaScript/TypeScript, if you are using this, you or a library you are using are doing it wrong, since you should know whether a value is a promise or not when writing code.
It's a part of node, at least: https://nodejs.org/docs/latest-v12.x/api/util.html#util_util...
See Promise.resolve https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
And is there a reason to use '!!' inside a conditional? Wouldn't obj&& do basically the same thing?
The predictable explosion in dependency trees has caused the predictable problems like this one. I feel I much prefer the C/C++ way of "modules are easy to make, but difficult to use".
class World { then () { return 0; } } isPromise(new World) // true
If there really isn't a safe and better way to tell if an object is an instance of Promise…then color me impressed.
(async () => ({
then() {
console.log("Called")
}
}))() const p = {then: () => 0}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.
Yes, this is by design. If this weren't the case, the ecosystem would be an absolute minefield of non-updated transitive dependencies with unpatched security issues.
And it's even worse in cargo, because specifying "1.2.1" means the same thing as "^1.2.1".
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.
The problem is when you try to level criticism at this culture and a cloud chorus of people will show up to assert that somehow tiny deps are good despite these glaring issues (a big one just being security vulns). And funnily enough, the usual suspects are precisely people publishing these one-liner libs. Then people regurgitate these thoughts and the cargo cult continues.
So there's no "fix" for NPM (not even sure what that would mean). I mean, anyone can publish anything. People just have to decide to stop using one-liner libs just because they exist.
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.
Of course it does. It's more bug-prone just by being a package. More code is more bugs and more build-system annoyance is more terror (=> more bugs). If I only need one line of functionality I will just copy and paste that line into my project instead of dealing with npm or github.
> Dependencies are part of your source
I agree. If you see news about broken packages like this and you don't just shrug your shoulders your build-system might be shit.
Dependency management is not as simple as you seem to think.
Pinning isn't meant to be a forever type of commitment. You're just saying, "all works as expected with this particular permutation of library code underneath." And the moment your dependencies release their hot-new you can retest and repin. Otherwise you're flying blind and this type of issue will arise without fail.
Users of Debian Stable missed Heartbleed entirely. It simply never impacted them.
I agree with the parent that it’s important to lock to avoid surprises (in Ruby, we commit the Gemfile.lock for this reason), but it’s equally as important to stay up to date.
1. https://nimbleindustries.io/2020/01/31/dependency-drift-a-me...
Github even bought Dependabot last year, so it's now free.
Works for existing apps, but people using create-react-app and angular CLI can't even start a new project.
Without doing that bit of diligence, this type of issue should be 100% expected.
It's also just not needed. Simply specifying an exact version ("=2.5.2") will avoid this problem. The code for a version specified in this manner does not change.
And then to see "npm detected 97393 problems" or whatever the message exactly is.
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.
This is manageable when you are using Packagist, this is manageable when you are using Maven, where all dependencies are flat. When compatibility issues arise they have to be dealt with upstream.
This is NOT manageable when you are using NPM that will go fetch 30 different versions of the same package because crazy dependency resolution.
This is not a JS issue like people claim here, this is 100% a NPM issue because whoever designed this was too busy being patronizing on Twitter rather than making sensible design decisions.
Sometimes I also take a look at the code.
And I've chosen the one with less dependencies often enough.
FWIW, I also won't add something to my project if I see it has a ton of dependencies on stupid shit. Literally, I gave up on react after realizing `create-react-app` is what the community recommends. I'm glad I did too. It's an insane amount of bloat, for nothing included but a view renderer, and if that's how that community rolls... I'm gonna have to pass.
If the code is in your codebase it does not need a test.
In fact, there are alternatives to React.
I wouldn't say getting started with ReactJS is easy (or that it's properly supported). Each team that uses React within the same company uses a different philosophy (reflected in the design) and sometimes these flavors differ over time in the same team. We're back to singular "wizards" who dictate how software is to be built, while everyone else tinkers. It's a few steps from custom JS frameworks.
There is no change to the actual functionality of the library. Only in the way it is packaged, here to support something that is an "experimental" feature in node.
It is also something that is hard to write automated tests for.
Meanwhile over in .Net-land, after 15+ years of smooth sailing (5+ if you only count from the introduction of NuGet), the transition from full framework to .Net Core has made a multi-year long migraine out of packaging and managing dependencies.
I ran into multiple scenarios where even Microsoft-authored BCL packages were broken and needed updates to resolve only packaging issues. It's a lot better now than during v1.x days, but I still have hacks in my builds to work around some still broken referencing bits.
POSIX was, for the most part, not a major success. The sheer dominance of Linux monoculture makes that easy to forget, though.
I think the effort that goes into all the JS syntax and module changes would be better put into developing a solid standard library first.
Promise.resolve({then: () => console.log('called')})
Promises autoflatten since you can't have Promise<Promise<T>>, so you'll see that this code prints 'called'.
This is the germane point in this incident.
The parent comment mentions that SemVer "guarantee[s] breaking changes are expressed through major versions". This is a common misperception about SemVer. That "guarantee" is purely hypothetical and doesn't apply to the real world where humans make mistakes.
The OP `is-promise` issue is an example of the real world intruding on this guarantee. The maintainers clearly didn't intend to break things but they did because everybody makes mistakes
Which points to the actual value proposition of SemVer: by obeying these rules, consumers of your package will know your _intention_ with a particular changeset. If the actual behavior of that changeset deviates from the SemVer guidelines (e.g. breaking behavior in a patch bump), then it's a bug and should be fixed accordingly.
Back to the parent's point about locking dependency version— I would add that you should also store a copy of your dependencies in a safe location that you control (aka vendoring) if anything serious depends upon your application being continually up and running.
In fact, how secure is it, really, to keep dependencies unpinned and welcome literally /any/ random upstream code into your project, unchecked? This is yet more irresponsible than letting dependencies age.
But even then, it's not as if you have to choose -- you can pin, then vet upstream updates when they come, and pin again.
That is: "^1.2.1" shouldn't be a bad default relative to "1.2.1"; you generally want to be able to pull in non-breaking security updates automatically, for what I hope are obvious reasons, and if that goes sideways then the blame should be entirely on the package maintainer for violating version semantics, not on the package/dependency manager for obeying version semantics.
I don't have much of an opinion on this for Node.js, but the Ruby and Elixir ecosystems (among those of many, many other languages which I've used in recent years) have similar conventions, and I don't seem to recall nearly as many cases of widely-used packages blatantly ignoring semantic versioning. Then again, most typically require the programmer to be explicit about whether or not to allow sub-minor automatic version updates for a given dependency, last I checked (e.g. you edit a configuration file and use the build tool to pull the dependencies specified in that file, as opposed to the build tool itself updating that file like npm apparently does).
That said, with a big enough team and risk-averse organisation, it can be a brilliant idea to put your dependencies in /separate/ version control and have your build process interact that way.
In that scenario, even if your dependencies vanish from the Internet (as happened with left-pad), you are still sitting pretty. You can also see exactly what changed when, in hunting for causes of regressions etc.
It's one thing if you own the entire codebase, but if you're building a popular, multiple-years-old library/framework, you can't make the same assumptions.
function isPromise(obj) {
return typeof obj?.then === 'function'
}The problem isn't reading 1000+ dependencies, the problem is the 1000+ dependencies... There's no way, setting up a view renderer, in the context of a webpage, requires a 1000+ dependencies. I honestly did this exact thing with `create-react-app` and it's one of the reasons why I don't use/choose react. Too much bloat for no batteries included.
Ignoring a common use case when inventing something is a good way to get your shit ignored in turn. Which is what happened.
https://github.com/adobe/react-webcomponent
By "aren't really there yet", what do you mean? If you mean in a sense of public adoption and awareness, totally agree.
If you mean that they don't work properly, heartily disagree. They function just as well as custom components in any framework, without the problem of being vendor-locked.
You may not be able to dig in to the internals of the component as well as you would a custom build one in your framework-of-choice, but that's largely the same as using any pre-built UI component. You get access to whatever API the author decides to surface for interacting with it.
A properly built Webcomponent is generally indistinguishable from consuming any other pre-built UI component in any other framework (Ionic built a multi-million dollar business of off this alone, and a purpose-built framework for it).
Doesn't excuse the JS ecosystem and JS as a whole, which truly is a mess. But there's a history behind these things.
If your API works with promises, call .then() on what is handed to you. That's it. Don't make up emergent, untestable behavior on the spot.
If you use the same one liners in more than one project and you copy that utility file over, the line gets even fuzzier.
Because the implementation detail of is-promise actually is important. It just checks if an object has a .then() method. So if you use it, it's just as important that you know the limitation.
Not everything needs to be swept under the rug.
And this would do nothing for the fact that `npm install eslint && ./node_modules/.bin/eslint` was also failing.
Not pinning dependencies is a security issue.
You can even automate updating to some degree -- running your tests against the latest everything and then locking in to those versions of all goes well.
Another good way to not have to depend on big/tiny/weird modules published by others is to use coffeescript. So much finicky logic and array-handling just goes away.
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.
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?
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.
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.
I’m running my project with ts 3.6. Library upgraded to 3.7 and adds null chaining operators. Now my package is broken. In node land, you compile the TS down to a common target before distributing so you don’t have this problem.
Similar, I’m using 3.8 and package upgrades to 3.9 and starts using some new builtin types that aren’t present in my TS. Now my package is broken. Previously you’d export a .d.ts targeting a specific version and again not have this problem.
Or, I want to upgrade to 3.9 but it adds some validations that cause my dependencies to not typecheck, now what?
Or, I’m using strictNullChecks. Dependent package isn’t. Trying to extract types now throws.
I’ve brought these all (And many other concerns) up to the deno folks on numerous occasions And never gotten a answer more concrete than “we’ll figure out what to do here eventually”. Now 1.0 is coming, and I’m not sure they’ve solved any of these problems.
This takes up _far_ less space than trying to commit your `node_modules` folder, and also works better cross-platform.
I wrote a blog post about setting up an offline mirror cache a couple years ago:
https://blog.isquaredsoftware.com/2017/07/practical-redux-pa...
Used it on my last couple projects at work, and it worked out quite well for us.
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
I don't understand how it applies to the OP problem. Even without "zero installs", yarn all by itself with a yarn.lock already ensures the same versions as in the yarn.lock will be installed -- which will still be a reproducible build as long as a given version hasn't changed in the npm repo.
(It looks to me like "yarn zero" is primarily intended to let you install without a reliable network and/or faster and/or reduce the size of your deployment artifacts; but, true, it also gives you defense against a package-version being removed or maliciously changed in the npm repo true. But this wasn't something that happened in OP case was it? A particular version of a particular package being removed or changed in repo?)
In this case, it was a new version that introduced the breakage, not changed artifact for an existing version. AND the problem occurs on trying to create a new project template (if I understand right), so I thin it's unlikely you'd already have a yarn.lock or a .yarn/cache?
Am i missing something? Dont' think it's related to OP. But it's a cool feature!
`yarn zero` protects you against dependencies disappearing, and lets you install without network connectivity.
I saw some work around changing versions in the package.json and lockfiles in the github issue. Instead of that, you could just roll back to the previous commit. Way easier. The package author also changed the earlier version after fixing it.
It would stop your shit from failing at least.
(Edit: I'm not quite sure how this would have completely prevented the issue? P'n'p is very good and seems to be a real step forward for JS package management but surely the same issue could have occurred regardless?)
Isn't this similar to not upgrading node and using an updated version of an npm package that calls a new function added to the standard library? All npm packages have a minimum node version, and similarly all deno code has a minimum deno version. Both use lockfiles to ensure your dependencies don't update unexpectedly.
> Or, I’m using strictNullChecks. Dependent package isn’t.
This definitely sounds like a potential problem. Because Deno enables all strict checks by default, hopefully library authors will refrain from disabling them.
Even TS project references make assumptions about the contents of package.json (such as the entry file), or how the compiler service for VsCode preloads types from @types/ better than for your own referenced projects, which sadly ties TS to that particular ecosystem.
Language version compatibility is a good point, but perhaps TSC could respect the compiler version and flags of each package's tsconfig.json, and ensure compatibility for minor versions of the language?
Since I enjoy working in TS I'm willing to wait it out as well, the pros far outweigh the cons. Now that GitHub/MS acquired NPM, I have hopes that it will pave the way to make TS a first-class citizen, though I don't know if Deno will be part of the solution or not.
That’s the problem - there is no tsconfig.json. You’re only importing a single URI.
Typescript partially solves that by declaring types, but if you have a any variable, you still need to do some probing to be able to safely convert it to a PromiseLike, because TypeScript goes to great lengths to not actually produce physical code on its output, attempting to be just a type checker.
Perhaps if TS or an extension allowed "materializing" TS, that is `value instanceof SomeInterface` generated code to check for the existence of appropriate interface members, this could be avoided, but alas, this is not the case.
I think that module over complicates it as it is, and most people don't need that level of complication in their code.
It's not perfect and a bit of a bolt-on, but io.ts works reasonably well in this area:
https://doc.rust-lang.org/std/primitive.bool.html#method.the...
https://doc.rust-lang.org/std/cmp/enum.Ordering.html#method....
At the same time, it is intensely wild to me that their "then" is an alternative to their "should", which apparently just re-executes the callback it's given until that callback stops throwing. If your tests require to be re-run an arbitrary and varying number of times in order to pass, you have problems that need to be dealt with in some better way than having your test harness paper over them automatically for you.
If a small standard library is using it for things that aren't promises, you can bet your ass that there are javascript libraries using it for things that aren't promises.
Like I said, I just chose to look at rust first because it's documentation has a good search bar.
A quick check of angular-cli and vue-cli shows that an empty project uses 870 and 816 dependencies respectively.
isFalse would be != isObject would use typeOf isFucntion would use typeOf
Where a library becomes helpful is when you have:
* A real problem (none of those are real problems, and the npm packages for them are essentially unused jokes)
* A solution that is not intuitive, or has a sharp edge, or requires non-obvious knowledge, or does not have a preexisting std approach
Checking for a promise, given the constraints of having multiple types of promises out in the world, falls into both of those. Checking if something is falsey, when Javascript provides !, does not fall into either.
I'm just saying it's neither necessary nor consistent with the standard for when a library is a good idea proposed upthread, so suggesting it as part of an attempt at reductio as absurdam on that standard is misplaced.
if a tree falls in the woods...?
When you cribbed the code you should have completely understood what exactly the package was doing, and why, and known what issues it would have had. Since it's a one-liner, it is transparent. Since it is without dependencies, it is unlikely to fail on old code. So it's unlikely to have existing issues and unlikely to develop new issues.
Of course, if you end up using new features of the language in your code, it may fail on that, but the risk old stuff failing should have already been factored in when you decided to upgrade. In fact, the one-liner solves this better since you decide the pace of adaptation of your one-liner to the new features, not the package maintainer.
ISTM that a framework may need to test for promiseness if it calls promises and functions differently, but it can and should be done as a utility in the framework, not as a separate package.
It’s possible to just treat everything as a promise by wrapping results in Promise.resolve() but that can have performance implications that some franeworks might want to avoid by only going down the promise route when they have to.
For promise implementations, If the callback to then() returns a promise, the promise implementation detects that and resolves that promise behind the scenes: http://www.mattgreer.org/articles/promises-in-wicked-detail/...
That also means that there would be a lot more updating when security issues are found.
as of 2020-04-26T00:39+00:00
Sorry, but I fear that ship has sailed ;-)
And I've heard JS was developed by someone who wanted to give us Scheme (you can't go more general purpose than that) but had to resort to a more "friendly" java-syntax. IMHO javascript would be a great general purpose language if the ecosystem wouldn't be such a mess.
I know, I know. If anyone needs me I'll be in the angry dome.
I guess that is a matter of time that the reality changes, we will not duplicate the number of developers indefinitely and experience and good practices will accumulate.
Taking into account the circumstances, we are not doing so badly.
You probably mean "double" here, but the bottom line is that there is zero data to back up that claim.
He literally made up that number out of thin air to make his talk look more important.
How does that change his original argument?
Part of the problem is a learning process, and indeed, I think the Javascript world should have learned some lessons - a lot of the mess was predictable, and predicted. Maybe next time.
But part of the problem is that we pick winners through competition. If we had a functional magic 8-ball, we'd know which [ecosystem/language/distro/OS/anything else] to back and save all the time, money and effort wasted on marketplace sorting. But unless you prefer a command economy, this is how something wins. "We" "picked" Linux this way, and it took a while.
Same with Covid, is roughly 20 years ago and people forgot there was SARS.
EDIT: also, Node's more than a decade old at this point, so it is at least a little bit surprising that the ecosystem is still experiencing these sorts of issues.
I've been stuck using it for about 4 years and it makes me literally hate computers and programming. Everything is so outrageously bad and wrapped in smarmy self congratulating bullshit. It's just so staggeringly terrible...
So these kind of catastrophes every few months for bullshit reasons seem kind of obvious and expected, doesn't it?
Make an iframe.
In the iframe:
> window.p = new Promise(() => {});
> window.frames[0].p instanceof Promise
false
[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
And it was given a Promise. You just shouldn't use instanceof in multi-window contexts in JavaScript. This is why built-ins like `Array.isArray` exist and should be used instead of `arr instanceof Array`. Maybe you'd prefer to write to TC39 and tell them that `Array.isArray` is wrong and should return false for arrays from other contexts?
There's no use jumping through hoops to avoid admitting that OP made an error. They were wrong and didn't think of this.
`obj instanceof Promise` and `typeof obj.then === 'function'` (is-promise) are much different checks. Frankly, I don't think either belongs in a library. You should just write that code yourself and ponder the trade-offs. Do you really just want to check if an object has a then() method or do you want to check its prototype chain?
https://www.typescriptlang.org/docs/handbook/advanced-types....
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.
Well, you can, and in the JS ecosystem you'll often find cases where there are two libraries (or two broad classes of libraries) for a certain function that make different choices, one of which makes the simple, modern choice that doesn't support legacy, and one that does the complex, messy thing necessary to deal with legacy code, and which you use depends on your project and it's other constraints.
Or did you mean something other than the US Census (e.g. GitHub or Stack Overflow or LinkedIn profiles)?
OTOH, historical BLS data is easy to look up.
That's why the next time I run into such a method, that doesn't belong to a promise and behave the way a promise's "then" method does, will be the first time I can remember, despite having worked primarily or exclusively in Javascript since well before promises even existed.
I'm sure there is an example somewhere on NPM of a wildcat "then", and that if you waste enough of your time you can find it. So what, though? People violate Rust idioms too from time to time, I'm sure. I doubt you'd argue that that calls Rust idioms themselves into question. Why does it do so with Javascript?
People bounce around between languages, especially to javascript. An expert javascript dev might not call things "then" but the many dabblers might. Going back to the original point this is a footgun, not only an avenue for malicious code to cause trouble.
There is zero evidence for his claim that the number of developers double every five years.
> The main focus should be dropping support for unsupported Node.js versions.
This literally is an XY problem: "I need to do A but it's giving me bad results, what do I need to add?" - "Don't use A, it's bad practice. Use B instead and keep using built-in tools instead of hacking something together" In this case use instanceof instead of is-promise because it's a hack around the actual problem of getting objects out of a different context that was explicitly designed to behave this way.
I'm afraid that you don't know what an XY problem is.
JavaScript developers always seem to think they are the smart ones after their 6 weeks of some random bootcamp and then you end up with some crap like NPM where a single line in a package out of hundreds maintained by amateurs can break everybody's development environment.
My primary point is just that you are mistaken when claiming that this bug could only be surfaced by malicious code.
My secondary (somewhat implicit) point is that having an "is-promise" function is a mistake when there is no way to tell if something actually is or is not a promise. This library/function name is lying to the programmers using it about what it is actually capable of, and that's likely to create bugs.
Absent that evolved level of tooling, and especially in an environment still dealing with the legacy of slow standardization and competing implementations that I mentioned in another comment, you're stuck with best effort no matter what. In the case of JS and promises, because of the norm I described earlier in this thread, best effort is easily good enough to be going on with. It's not ideal, but what in engineering practice ever is?
With javascript promises in particular, the duck typing suffers from this unfortunate fact that you can't easily check if something can be awaited-upon or not. I don't think I really care if something is a promise, so long as I can do everything I want to to it. So I view the issues here as this function over-claiming what it can do, the limitation on the typesystem preventing us from checking the await-ability of an object, and the lack of static type checking. None of those are necessitated by duck typing.
I disagree that you're stuck with this best-effort function. It's perfectly possible to architect the system so you never need to query whether or not an object is a promise. Given the lack of ability to accurately answer that question, it seems like the correct thing to do. At the very least I'd prefer if this function was called "looks-vaguely-like-a-promise" instead of "is-promise".
I don't care enough to go dig that out on a Saturday afternoon, but I suspect that if I did, we'd end up agreeing that whoever is using it could, by dint of sufficient effort, have found a better way.
On the other hand, this appears to be the first time it's been a significant problem, and that only for the space of a few hours, none of which were business hours. That's a chance I'd be willing to take - did take, I suppose, in the sense that my team's primary product is built on CRA - because I'm an engineer, not a scientist, and my remit is thus to produce not something that's theoretically correct in all circumstances, but instead something that's exactly as solid as it has to be to get the job done, and no more. Not that this isn't, in the Javascript world as in any other, sometimes much akin to JWZ's "trying to make a bookshelf out of mashed potatoes". But hey, you know what? If the client only asks for a bookshelf that lasts for a minute, and the mashed potatoes are good enough for that, then I'll break open a box of Idaho™ Brand I Can't Believe It's Not Real Promises and get to work.
I grant this is not a situation that everyone finds satisfactory, nor should they; the untrammeled desire for perfection, given sufficient capacity on the part of its possessor and sufficient scope for them to execute on their visions, is exactly what produces tools like Typescript, that make it easier for workaday engineers like yours truly to more closely approach perfection, within budget, than we otherwise could. There's value in that. But there's value in "good enough", too.