Hacker News Reader

Comment by programmer_dude | Hacker News Reader

Read the NPM doc but I still don't understand what "ejection" is. What are we ejecting? Can someone explain this please?

View on HN

> What are we ejecting?

Ourselves, it seems. A Javascript framework is like a jet, and we are the human payload. You can stay in the jet, zooming over the constantly changing landscape. But if you get tired of this zooming around (or if you get scared of hitting a mountain), then you can activate the ejection seat (https://en.wikipedia.org/wiki/Ejection_seat). Of course, now you're a mile high without a plane, but the ejection-seat comes with a parachute, so the descent will be pleasant (or, at least, non-fatal - which is a style of pleasantness).

Erm, wait, I think you were soliciting a more literal answer. :)

"create-react-app" is the Javascript framework/jet. If you want to go for the ride, then you declare a single-dependency on "create-react-app", and they will decide when/what/how to upgrade components in the framework. If you don't want to ride along with "create-react-app"s framework, then you "eject". They'll give you a little bundle (the concrete list of dependencies) and send you off on your way.

LOL, best answer so far!

I tried this and landed in a field of debris from the jet.

I believe the confusing bit is that it's not an NPM thing, it's a create-react-app thing. create-react-app is a helper tool for, as the name says, creating React applications and doing a bunch of things out of the box. Occasionally you reach the point where you need to do something more complex than create-react-app can handle for you. In that case, you run the "eject" script in the generated app (using "npm run" as the runner), which removes create-react-app's automatic build dependency from your project and sets it up as if you had put together all the pieces by hand. But create-react-app still works, for the most part.

(In this context, I think what is being "ejected" is the build dependency automatically added by create-react-app.)

I don't think it's a perfect analogy, but I see what the author is getting at - you need to break the abstraction of some packaging tool, but you want the functionality it provided to still work as well as possible.

I think you're correct that the eject mechanism was popularized with react. It very much sucks IMHO. At least yarn has a mechanism to override a dependency with your own version of a component.Therefore I am not sure the article is totally correct on this

> I don't think it's a perfect analogy, but I see what the author is getting at - you need to break the abstraction of some packaging tool, but you want the functionality it provided to still work as well as possible.

You got it. I don't think it's the best analogy either but it is pithy and works if you squint.

The essence is:

1. create-react-app is a monolithic transformation of a bunch of disparate tools into a managed workflow.

2. You can update create-react-app like any other dependency and get updates to the workflow.

3. At any point, you can break the abstraction via `npm run eject`, which drops you down a level into the raw configuration for the "disparate tools" that create-react-app was acting as a veneer over. This ejection is a point in time transformation, you no longer get the managed workflow updates from (2).

The analogy was:

1. The Linux kernel package on $DISTRO is a monolithic transformation of Linux kernel source code to Linux kernel binaries.

2. You can get updates from the package manager.

3. At any point, you can break the abstraction by dropping down a level and forking the current packaging script to adjust the transformation (like applying a patch). This fork is a point in time transformation, you no longer get the package updates from (2).

The Open Build Service and its version control tool, osc, offer some ability to fork a package from an upstream repo and still track upstream changes. It's not as elegant or convenient as Nix, but it is pretty cool. OBS supports packages for a ton of distros. It's essentially patch based, but targeting different distros (of the same package type) and different architectures can sometimes be without changing the source packages at all.

It might be fun to compare their approaches to solving this ejection problem. Nix's is much nicer to use and requires basically no infrastructure, of course.

It’s not a common package manager or NPM thing, but a create-react-app thing that a few other things have copied. A detailed description of what it involves in CRA is here: https://create-react-app.dev/docs/available-scripts/

My general understanding is that ejection means you are abandoning a state that can safely accept updates from the original source.

"You're on your own, buddy. Good luck!"

Reply on news.ycombinator.com