One thing you can do is fork, and then add your fork to your project as a git submodule and add the submodule to the list of source directories in elm.json. Like this, you can iterate until you have made the update that felt right for your use case. If you want to contribute back you can contact the author of the original package and ask if they are interested in your update. Unless if those are too specific, or maintainer does not have time, people are usually happy to get feedback with a concrete use case to improve their package.
The above solutions work but are a bit of a hassle. One major short-coming is that the transitive dependencies are not dealt with when you put a source path to another package in your elm.json; you must also install any transitive dependencies too.
I think something like elm-github-install really needs to be brought back. Perhaps a better name for it might be elm-git-install. In addition to the elm.json file there would be a second elm-git.json file, that provides optional overrides to dependencies, either to a location on the local file system, or some git repo (+ optional tag). There would be a command elm-git install, that does the necessary installation work based on the contents of elm.json and elm-git.json and more gracefully handles the transitive dependencies.
This would make it much simpler to work with forked but not yet re-published packages, to fix bugs in core packages and test them, and for larger software systems to make use of private packages that should be kept internal to some organisation and are not intended to be published.
No, as that only installs the packages without their transitive dependencies.
Also, that did not support the local filesystem or a git branch as an install source. Local filesystem is very useful if you were working on fixing a bug or doing something experimental in say elm/virtual-dom - you might want to test changes you made without pushing back to your fork, or you might want to test a branch without a tag during development (you can use the git SHA at least).
I’m guessing it’s because the tool supports writing packages containing JS and the readme contains the line
Note: Best not talk about this on the offical Elm channels unless you’re trolling.
To be clear then, I linked it because I thought it might support @rupert’s use case and I suggested elm-git-install first to avoid unnecessarily promoting tools that promote writing packages with kernel code.
Just to be clear, I am not advocating for a tool that lets you write and share new packages containing kernel code. I would like a tool that supports 2 use cases, and I think these do not in any way subvert the purity of Elm packages:
Private packages (not containing kernel code).
The ability to modify packages that do contain kernel code and build them locally. This is to assist with bug fixes or other feature experimentation. It would not be possible to publish these as they would need to be in the elm or elm-explorations namespaces. Technically it would be possible to share them as any override to the git URL would be supported by this tool - but I think end users would be very aware that they are using forked kernel packages. I think not being able to publish them to the official repo would make them irrelevant anyway.
I’d sooner have use case 1 over use case 2. Perhaps use case 2 has a better solution?
For example, TSFoster and myself collaborated on a fix for a non tail recursive function in the debugger that is occasionally blowing the stack on larger models. I never figured out how to test the patch though, so have never created a PR for it. Seems a shame to miss out on little bug fixes like this for lack of a simple way to test them: