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

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

github.com

Post reply on HN
Print view View original

281–290 of 478 posts

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

#281

Post by acemarke »

jrochkind1 wrote: post #276
_630w wrote: post #214

Earlier quoted context omitted.

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.

What's "yarn zero installs"? Googling did not do it for me.

That might be referring to Yarn's "offline mirror" feature. When enabled, Yarn will cache package tarballs in the designated folder so that you can commit them to the repo. When someone else clones the repo and runs `yarn`, it will look in the offline mirror folder first, and assuming it finds packages matching the lockfile, use those.

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.

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

#282

Post by jakear »

halfmatthalfcat wrote: post #230
aylmao wrote: post #126

Earlier quoted context omitted.

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

Deno was always Typescript-first fwiw

I have doubts about how this could possibly work. The idea is you pull a .ts file directly, right? Then your local ts-in-debo compiles that to extract typedefs for intellisense/etc and the JS. What happens when it was created for a different version of typescript than what you’re running? Or if it was created targeting different flags that what you’re using? This will cause lots of problems:

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.

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

#283

Post by jbverschoor »

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

Digging requires depth. 1 line modules aren’t depth.

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

#284

Post by acemarke »

throwanem wrote: post #241
gavinray wrote: post #232

Earlier quoted context omitted.

This is slightly off-tangent, but as someone who has written production software on the front-end (small part of what I do/have done) in: 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 ar…

Web components aren't really there yet. They will be two or three years from now. Some time between now and then, I expect React will gain the ability to compile down to them, which shouldn't be too hard since web components are pretty much what happens when the React model gets pulled into core.

Very unlikely. Web components and React are trying to solve different problems, and the React team has repeatedly said this isn't going to happen.

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

#286

Post by rhizome »

morelisp wrote: post #121
throwanem wrote: post #107

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

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…

>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

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.

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

#287

Post by michaelcampbell »

oldmanhorton wrote: post #210
hu3 wrote: post #196

Earlier quoted context omitted.

There are alternatives to create-react-app. In fact, there are alternatives to React.

Have fun telling that to your boss

Or the 25 people you work with across 4-8 different teams that finally settled on something that can allow people of different teams to move around without a lot of anguish.

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

#288

Post by dgellow »

Hokusai wrote: post #267
throwanem wrote: post #225

Earlier quoted context omitted.

Yes, that's largely my point. I'm not sure why it is surprising to see an ecosystem, twenty-five or so years younger than the one I compared it to, have the same problems as that one did twenty-five years or so ago.

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

Do you have the source? Sounds like an interesting talk.

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

#289

Post by jakear »

tomphoolery wrote: post #269
aylmao wrote: post #126

Earlier quoted context omitted.

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

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

The problem I saw was how quickly you need to open up the permissions floodgates. I saw them live-demo a simple http server, and to do something as basic as that you need to open up full file system and network access. So if you’re doing anything like setting up a server (i.e. one of the core things one does when using a server-side scripting language), you’re back to square 1.

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

#290

Post by stefan_ »

city41 wrote: post #218
devit wrote: post #209

Earlier quoted context omitted.

A function like this should not be something that anyone even thinks of writing or using. 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 wr…

This function is most likely an artifact of before promises got standardized. One way promises took off and became so ubiquitous is different implementations could interop seamlessly. And the reason for that is a promise was defined as 'an object or function having a then method which returns a promise when called'. Doesn't excuse the JS ecosystem and JS as a whole, which truly is a mess. But there's a history behind…

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.

Post reply on HN