- Dec 2020
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
You can also see this repo: default-passive-events.
- Sep 2020
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.
- 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
- 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
- forking to add a desired missing feature/change
- trying to prevent one bad thing leading to people doing/choosing an even worse option
- maintenance burden to explicitly define/enumerate/hard-code possible options (explicit interface)
There's no way to change style incapsulation method without patching the compiler, and this means maintaing a fork, which is not desirable.