Conversation
|
@andrewharvey @arch0345 (picking the most active contributors) getting this reviewed and merged would unlock quite a few upstream use cases. Can you share what we would need to do to get this going? If it helps, lets get together at some meetup like the iD Community Chat (next: 10th May 10:00 – 11:00 (UTC)) and discuss status quo and next steps. |
|
I'd love to see this move forward, however I unfortunately don't have the necessary permissions to make the two highlighted changes in the PR description to make this work. It looks like @tyrasd has the permissions to make changes to the npm package and I believe @iandees should be able to create the new environment on this repo |
|
I really don't understand what the supposed benefits of this are. Using a packaged version gets you a stale version of the database, with broken and missing layers. What are you hoping to achieve with this? I with iD switched to grabbing the URL directly, or at least caching/refreshing it. |
software releases are a very normal concept, if every app pulled dependencies from other peoples' afaik, there's unequivocal agreement that software releases are still an important thing. unless the vibe-coders are trying to change that? 😆
well, currently iD users get a 3-to-6-month-old version of ELI.... this would improve the situation from 6 months to a few days. and if ELI was "broken", a maintainer could fix that in minutes, instead of months |
Based on the recent discussions, it sounds like everyone supports the idea of publishing releases.
So, now that #2917 is merged, this PR adds a button to the GitHub UI, which a maintainer can click to publish a new version to npm:
There's no authentication tokens required, and this runs completely in the CI, maintainers don't need to run any commands locally.
Before this can be merged, there are a few extra steps that a maintainer needs to take (click to expand)
npm. Setup whatever restrictions you want, like only allowing deployments from thegh-pagesbranch.Once these two steps are done, publishing will work from the GitHub CI without needing to setup any other authentication or permissions. (thanks to the 'trusted publishing' feature)