- Apr 2025
-
www.npmjs.com www.npmjs.com
-
This project is a fork of motdotla/dotenv. The difference is this project by default overrides system environment variables.
Not a need that I have, but I guess they felt a need for it
-
- Mar 2025
-
github.com github.com
-
Fork your own copy of drizzle-kit and update src/serializer/pgSerializer.ts
-
Modify your local node_modules/drizzle-kit/bin.cjs file and modify line
-
- Sep 2024
-
-
It's a fork of Memery gem. Original Memery uses prepend Module.new with memoized methods, not touching original ones. This approach has advantages, but also has problems, see discussion here: tycooon#1
-
- Jan 2024
-
gitlab.com gitlab.com
-
(I grant that many of us contribute code to Gitlab, and would also like to participate as members of the development team in guiding the implementations, but clearly the core team has to have the final say in what direction that takes... unless someone wants to create and maintain their own fork of Gitlab ;) )
-
- Dec 2020
-
www.npmjs.com www.npmjs.com
-
No more waiting around for pull requests to be merged and published. No more forking repos just to fix that one tiny thing preventing your app from working.
This could be both good and bad.
potential downside: If people only fix things locally, then they may be less inclined/likely to actually/also submit a merge request, and therefore it may be less likely that this actually (ever) gets fixed upstream. Which is kind of ironic, considering the stated goal "No more waiting around for pull requests to be merged and published." But if this obviates the need to create a pull request (does it), then this could backfire / work against that goal.
Requiring someone to fork a repo and push up a fix commit -- although a little extra work compared to just fixing locally -- is actually a good thing overall, for the community/ecosystem.
Ah, good, I see they touched on some of these points in the sections:
- Benefits of patching over forking
- When to fork instead
-
- Nov 2020
-
github.com github.com
-
You can also see this repo: default-passive-events.
-
- Sep 2020
-
github.com github.com
-
Svelte will not offer a generic way to support style customizing via contextual class overrides (as we'd do it in plain HTML). Instead we'll invent something new that is entirely different. If a child component is provided and does not anticipate some contextual usage scenario (style wise) you'd need to copy it or hack around that via :global hacks.
Tags
- trying to prevent one bad thing leading to people doing/choosing an even worse option
- workarounds
- forking to add a desired missing feature/change
- Svelte: how to affect child component styles
- component/library author can't consider/know ahead of time all of the ways users may want to use it
- ugly/kludgey
- forced to fork/copy and paste library code because it didn't provide enough customizability/extensibility / didn't foresee some specific prop/behavior that needed to be overridable/configurable (explicit interface)
- run-time dynamicness/generics vs. having to explicitly list/hard-code all options ahead of time
- maintenance burden to explicitly define/enumerate/hard-code possible options (explicit interface)
Annotators
URL
-
-
github.com github.com
-
There's no way to change style incapsulation method without patching the compiler, and this means maintaing a fork, which is not desirable.
-