undefined | Better HN

0 pointsrraval4y ago0 comments

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

0 comments

pxc4y ago

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.

j / k navigate · click thread line to collapse