Open ajp8164 opened 2 years ago
Considering the complexity of that feature, (and you're usually editing built assets) I'm not super into the idea that it should live in patch package.
That said, I think we could have a command which re-uses the github cli to do some of that work potentially?
a first step would be https://github.com/milahu/patch-package/issues/13
Considering the complexity of that feature, (and you're usually editing built assets) I'm not super into the idea that it should live in patch package.
That said, I think we could have a command which re-uses the github cli to do some of that work potentially?
Idea - the devs patch process can force the dev to patch original source and then use an automated process to create the runtime patch. As @milahu suggests, the use of a repo (essentially a behind the scenes form) seems fairly straightforward.
I'm my experience forking and submitting is a painful process and could be nearly fully automated. The goal is to encourage devs with an easier process to contribute changes. Next step is to decentralize repo ownership (blockchain style) to keep repos updated. Maintainers leave a lot of good repos and so getting a single core of maintainers out of the process would be ideal. IMHO :-)
decentralize repo ownership
deno is one way to get rid of NPM (because we cant get rid of typescript ...)
forking and submitting is a painful process
writing such a "killer app" is painful too, mostly because nobody will use it (marketing no demand)
I like the sentiment of patch-package. I wish it would automagically generate a PR for the source repo though (on its own in a scratch space or wherever). To make this work we'd need a very well defined process to handle interactions prior to merge. This package does great at getting me going right now without having to fork etc (which always seems like a huge hassle, including follow ups etc). Seems to me that patch-package produces brittle apps and falls short in promoting "bug free" ;-) open source packages.
I think it doesn't make much sense for the following reasons:
patch-package
mostly because maintainers have refused to accept our PRs or improvements.
patch-package
is the 'last resort', and when we have to use it, it is likely that the maintainer has already rejected our PR more than once..js
and .d.ts
files, not the typescript source. How can we 'merge' our suggestion into the original repository under these cases?which always seems like a huge hassle, including follow ups etc
Of course, I totally agree with you. But I can't think this is 'more proper' way than an ordinary fork-than-PR based process.
I like the sentiment of patch-package. I wish it would automagically generate a PR for the source repo though (on its own in a scratch space or wherever). To make this work we'd need a very well defined process to handle interactions prior to merge. This package does great at getting me going right now without having to fork etc (which always seems like a huge hassle, including follow ups etc). Seems to me that patch-package produces brittle apps and falls short in promoting "bug free" ;-) open source packages.