A one-line package broke `npm create-react-app` • Hacker News Board

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

#421

Post by forty » Sun, Apr 26, 2020, 8:54 AM UTC

staticassertion wrote: post #45

chvid wrote: post #7

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

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

No. There is no reason why it should be a package by itself. It should be part of a bigger util package, which which is well maintained, tested, and with many maintainers actively looking at it, with good processes, such as systematic code reviews, etc.

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.

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

#422

Post by chvid » Sun, Apr 26, 2020, 9:13 AM UTC

mikewhy wrote: post #309

franciscop wrote: post #277

Earlier quoted context omitted.

From those commits, it seems this issue was fixed in 1h12min. That should be a new record, specially considering this is all volunteer work on a Saturday. While it's bad that things break, the speed at which this was fixed is truly amazing. A big thank you to everyone involved here.

Not sure where you're getting 1h12 from. First issue was reported at 12:18pm (my time) final update that fixed it was published at 3:08pm. 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 the…

This is a good example of how terrible messy JavaScript library creation is.

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.

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

#423

Post by darekkay » Sun, Apr 26, 2020, 9:32 AM UTC

Ndymium wrote: post #306

Pfhreak wrote: post #226

Earlier quoted context omitted.

What's the difference between a utility file and a package? That seems like a distinction without a difference to me. If you use the same one liners in more than one project and you copy that utility file over, the line gets even fuzzier.

The utility file will never be updated and break your build without you doing it yourself.

Also: The utility file will never be updated and fix existing issues within the utility itself (unless you look up the package and diff it yourself). It's a trade-off.

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

#424

Post by Aeolun » Sun, Apr 26, 2020, 10:31 AM UTC

gav wrote: post #33

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

I’d argue that ‘index.mjs’ is a relative URL.

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

#425

Post by jhanschoo » Sun, Apr 26, 2020, 11:40 AM UTC

darekkay wrote: post #423

Ndymium wrote: post #306

Earlier quoted context omitted.

The utility file will never be updated and break your build without you doing it yourself.

Also: The utility file will never be updated and fix existing issues within the utility itself (unless you look up the package and diff it yourself). It's a trade-off.

As the commenter who suggested keeping it in a utilities file, I'd say that the trade-off is heavily weighted to not importing it as a package.

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.

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

#426

Post by mlsarecmg » Sun, Apr 26, 2020, 11:55 AM UTC

rubyn00bie wrote: post #365

tirpen wrote: post #270

Earlier quoted context omitted.

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

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

this doesn't make any sense. cra is webpack, but in a way that doesn't blow up every week. you can use react without bundlers, but what is the point. you'll be sitting there, without a dev env, no hot reload, no module resolution, minification, types, jsx, babel, ... any single one of these will get you 1000+ packages on the dev side. none of this is going into the published build of course.

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

#427

Post by Aeolun » Sun, Apr 26, 2020, 12:03 PM UTC

hota_mazi wrote: post #404

Hokusai wrote: post #267

Earlier quoted context omitted.

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

> The number of developers duplicates each 5 years 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.

It should be fairly simple to look up people describing themselves as developers in the census data I think?

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

#428

Post by earthboundkid » Sun, Apr 26, 2020, 12:07 PM UTC

city41 wrote: post #301

stefan_ wrote: post #290

Earlier quoted context omitted.

I think the point of the comment is: you should not be testing for this at all . 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.

You need to do this test if you are creating a promise implementation. That was my point, there is a reason code like this exists.

Why would an implementation need to test for it?

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.

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

#429

Post by adrianhel » Sun, Apr 26, 2020, 12:24 PM UTC

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.

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

#430

Post by darekkay » Sun, Apr 26, 2020, 12:59 PM UTC

jhanschoo wrote: post #425

darekkay wrote: post #423

Earlier quoted context omitted.

Also: The utility file will never be updated and fix existing issues within the utility itself (unless you look up the package and diff it yourself). It's a trade-off.

As the commenter who suggested keeping it in a utilities file, I'd say that the trade-off is heavily weighted to not importing it as a package. 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 unlik…

That's the trade-off I would most likely take in the "isPromise" case. But the opening question was a generic one ("What's the difference between a utility file and a package"), so the answer should reflect both sides.