
Show HN: Quickfix, the best stupid idea for fixing problems in Node modules - flaque
https://github.com/maxchehab/quickfix#quickfix
======
partycoder
A safer way in my opinion is to:

0\. read module license

1\. checkout the module to be patched

2\. modify it

3\. do "npm pack" to save a tarball

4\. set the dependency version in your package.json to the tarball. and make
sure to the tarball is available during build time.

5\. report the issue in their issue tracker for long term fix.

In contrast:

with this "quick fix", the dependency can change, or the transient
dependencies can change. This would cause the quickfix patch to not apply
anymore.

The only way to guarantee that it won't break is to save the module and all
its dependencies. Something that is equivalent to npm pack.

Finally... don't get yourself into a licensing problem. Take a good look at
the license before modifying a project.

~~~
charlesetc
Does npm even allow you to use projects that don't allow you to make changes
to their code?

~~~
partycoder
You can have an npm module with any arbitrary licensing.

[https://docs.npmjs.com/files/package.json#license](https://docs.npmjs.com/files/package.json#license)

------
andreineculau
Leaving aside the comedic factor, albeit problem-solving, if you want a sane
alternative check out pnpm. It will not only make the installation of deps
faster but it will also allow you to override a dependency on any n-level e.g.
a dependency of a dependency.

A dependency published a patch version with a breaking change and the author
is on vacation? No problem, you can lock it within your project to the
previous version.

Did you fork a dependency and you want to use your version? You can do that
too. In all of your dependency chain. You can even change the version
specifier to a git url so no need to publish your fork to the npm registry.

I whole heatedly recommend anyone to have a look at pnpm. As a unix dev,
there's so much in there that is well thought and kept simple this fast.

[https://github.com/pnpm/pnpm/blob/master/README.md#hooks](https://github.com/pnpm/pnpm/blob/master/README.md#hooks)

~~~
exogen
That’s an interesting approach to it (modifying how the package.json is
processed).

If anyone is wondering if their current package manager supports this, it does
if you are using Yarn. Yarn has a `resolutions` field to override subdeps
(either globally or in a targeted way):
[https://yarnpkg.com/lang/en/docs/selective-version-
resolutio...](https://yarnpkg.com/lang/en/docs/selective-version-resolutions/)

It’s not as low-level and flexible as pnpm’s approach, but is perfect for the
use case described here.

~~~
andreineculau
Correct. The pnpm approach is more versatile. You can do anything to a
dependency's package.json . I have recently used it to debug and then monkey
patch "scripts" (property) invocations without even forking the dependency.

------
fiatjaf
Oh, that's terrible, awful, the worst idea ever! You're promoting bad
practices, the quality of code will only get worse from now on! Someone needs
to delete this thread! You must have quality guidelines, code review, follow
best practices! Don't you dare modifying the content of node_modules!

[secretly uses quickfix when no one is looking]

~~~
maxchehab
As the creator, I shame you :)

------
Benjamin_Dobell
One of the really nice things about NPM (and other modern source-level
dependency managers) is that it's trivial to fork dependencies and reference
commits in remote Git repositories. This workflow makes it really straight
forward to patch third-party dependencies. Combine it with a lock file for
reproducible builds and you're good to go with minimal fuss.

~~~
Sujan
How (well) does this work in a dependency of a dependency of a dependency?

~~~
Benjamin_Dobell
You have three options:

1\. Fork every dependency in the chain. Which typically isn't more than two or
three dependencies.

2\. Fork the distant dependency, and specify it as a direct dependency.

3\. Fork the distant dependency, and _only_ update your lock file.

Option 1 is probably the "correct" approach, and sometimes necessary anyway,
if you've made contract/API changes to a dependency of a dependency. It will
also make it easier to contribute your changes upstream - which presumably
you're wanting to do to avoid the maintenance burden of maintaining forks.

Option 2 is the "easiest", but probably least correct as you're adding a hard
dependency where one shouldn't exist.

Option 3 works fine until you try regenerate your lock file.

Quickfix doesn't seem to take itself too seriously, which is nice, but I'd
happily argue that any one of the 3 approaches given above is better than the
approach Quickfix is taking.

------
nautical
We had same issue and we used diff and patch.

~~~
zbentley
That's basically all this is, but with fewer commands to remember and modify.
I think that's quite useful, especially when under lots of time pressure.

------
arthurcolle
This is a terrible idea and I encourage you to consider the slipperiness of
this slope

~~~
skrebbel
Pragmatism is on a slipperly slope almost by definition.

~~~
zbentley
That is a very concise way of saying something I've struggled to articulate
well in the past.

Sometimes stuff like this is a horrible idea. Sometimes you need it. If you
lock out the entirety of the "sometimes you need it" use cases as "too
dangerous if applied en masse", you cripple yourself. Remember: not everyone
has the time to do it right (the time they have might be measured in minutes
or seconds before a push or bugfix), or the wherewithal or ability to even
learn how. You can lament that reality if you like, but tools that accept it
will be useful anyway.

------
rendall
Clever and funny. I might find this useful for broken Typescript typings that
have been somehow included in the package.

------
limsup
Check in your node_modules. You are badly correcting the wrong problem. npm
repo should not be hit for every checkout, deploy, and CI test. Just commit
your dependencies - and if you need to hack them, you can float a patch with
git.

~~~
shabbyrobe
Watch out! The "pure and perfect git history is more important than any other
consideration" crowd are going to take you apart for this heretical notion!

~~~
orf
More like the "we don't want a 10gb git repo" crowd to be honest.

Checking in not only your code, but your entire history of every dependency
and every change within that dependency graph is an amazingly bad idea when
frontend apps often have 600mb+ of dependencies that change somewhat
frequently, and git keeps a version of every file in its history.

~~~
mattwad
But you're going to have to install them either way. We only update
dependencies when they are needed, so in practice this is rarely an issue. We
have also gotten in the practice of making separate branches for updates to
keep Pull Requests sane.

~~~
orf
Part of my current project has a node_modules folder that is 400MB and
contains 37853 files. Seeing as updating a dependency can cause a cascading
effect that can touch a lot of different files, it's not a good idea to store
them in git. It's akin to the reason you don't store binary files in git.

If installs are too slow, switch to a caching yarn/npm mirror. Cloudflare has
one. Or run a local caching proxy for your team.

------
jwilk
README would be 42% better without megabytes of pointless animated GIFs.

~~~
jchw
I'm not that amused either, but to each their own. It's only 2 megabytes,
which is probably a lot less than your average `yarn`/`npm install` session.

~~~
jwilk
2 megabytes is at least 30 seconds of hogging my Internet connection.

I never use npm on the same machine that I browse web, so for me the two
things aren't comparable.

