Also, we might want to have a broader conversation since we have other initiatives improving the nodejs ecosystem, see T357950: Remove servicerunner dependency for cxserver

I am removing RESTBase Sunsetting as this is not needed for its completion. Please, re-add it if needed.

@Chickenleaf: Hi and thank you for your interest! Please check https://www.mediawiki.org/wiki/New_Developers (and its communication section). The page covers how to get started, assigning tasks, task status, how to find a codebase, how to create patches, where to ask general development questions and where to get help with setup problems, and how to ask good questions. Thanks a lot! :)

Hello! @Reedy can i be assigned this? Im new to more organized large scale open-source projects and would like to begin my contribution to them with wikimedia.

Getting rid of service-scaffold-node also means we should get rid of servicelib-node since it was created for service-scaffold node (this is the reason why service-scaffold node depends on packages that don't exist. This project never finished)

Final step needs a gerrit admin.

@Nikerabbit Yea, I meant to tag you for visibility, I don't think there is any action to take on your end outside of awareness. We had talked about this ticket in our team meeting and Daniel mentioned that language team should be aware of node scaffold changes. It is on our radar column.

@FJoseph-WMF Did you mean Language-Team? What's expected from us?

Change #1035058 merged by jenkins-bot:

[integration/config@master] jjb: Drop {trigger-,}service-scaffold-node-pipeline-test, now unused

https://gerrit.wikimedia.org/r/1035058

Mentioned in SAL (#wikimedia-releng) [2024-05-22T23:02:35Z] <James_F> Zuul: Archive mediawiki/services/service-scaffold-{node,golang} for T365512

Change #1035057 merged by jenkins-bot:

[integration/config@master] Zuul: Archive mediawiki/services/service-scaffold-{node,golang}

https://gerrit.wikimedia.org/r/1035057

Change #1035060 merged by Jforrester:

[mediawiki/services/service-scaffold-golang@master] Empty repo

https://gerrit.wikimedia.org/r/1035060

Change #1035060 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/services/service-scaffold-golang@master] Empty repo

https://gerrit.wikimedia.org/r/1035060

Change #1034549 merged by Jforrester:

[mediawiki/services/service-scaffold-node@main] Empty repo

https://gerrit.wikimedia.org/r/1034549

Change #1035058 had a related patch set uploaded (by Jforrester; author: Jforrester):

[integration/config@master] jjb: Drop {trigger-,}service-scaffold-node-test, unused

https://gerrit.wikimedia.org/r/1035058

Change #1035057 had a related patch set uploaded (by Jforrester; author: Jforrester):

[integration/config@master] Zuul: Archive mediawiki/services/service-scaffold-{node,golang}

https://gerrit.wikimedia.org/r/1035057

Sounds good to me. service-scaffold-node was started to turn service-template-node into a group of libraries and is basically superseded by my effort to replace service-runner (T360924) which is mostly completed

Change #1034549 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/services/service-scaffold-node@main] Empty repo

https://gerrit.wikimedia.org/r/1034549

In T340105#9805519, @daniel wrote:

We had a meeting about this yesterday, with Bill, Thomas, Chris, Andrew, Daniel, Timo, Roan, Subbu

There seems to be a lot of support for the idea.

Below is a summary of our discussion, paraphrased based on my memory:

We had a meeting about this yesterday, with Bill, Thomas, Chris, Andrew, Daniel, Timo, Roan, Subbu

In T340105#9682152, @Eevans wrote:

Is there any drawback to having a separate library, managed using whatever system is idiomatic to the language? Or conversely, is there an advantage to having projects be a fork of the template?

In T340105#9680692, @Krinkle wrote:

This is relevant to an issue we discussed at the offsite last month around offering teams the option to migrate legacy Node.js services to e.g. the new MediaWiki REST API (extension) and/or a standalone PHP service (if indeed it qualifies to be its own service, under latest SRE guideance at https://www.mediawiki.org/wiki/Wikimedia_services_policy and T239856).

Change #1023810 had a related patch set uploaded (by Aklapper; author: NewtonKamau):

[mediawiki/services/wikifeeds@master] Logo: Updated Logo Link

https://gerrit.wikimedia.org/r/1023810

In T340105#8957849, @Tgr wrote:

One more hypothesis for PHP IMO is that it requires significantly less long-term maintenance effort than Node when base OS versions (and as a consequence language versions) change, because the library ecosystem tends to be more stable. (Not sure how to quantify and test that, though; it's just a personal impression based on how abandoned Node services fared. Also, no idea if the same is true for Go.)

This is relevant to an issue we discussed at the offsite last month around offering teams the option to migrate legacy Node.js services to e.g. the new MediaWiki REST API (extension) and/or a standalone PHP service (if indeed it qualifies to be its own service, under latest SRE guideance at https://www.mediawiki.org/wiki/Wikimedia_services_policy and T239856).

Considering how much time has passed, it's probably safe to say this is complete. If not, please reach out :)