It should be possible to customise the implementation of mw.util.addPortletLink function on a skin basis

This sounds like a sensible idea to me. A skins major responsibility is customizing DOM output, so why should skins have to conform to an html structure that might not be suitable for them?
Here's an idea: could we pass mw.util.addPortletLink a mustache template on a per-skin/per-menu basis?

I'm very excited about this proposal and eager to adopt a modern framework like Vue!
I think there's still a lot of infrastructure that needs to be put in place to take advantage of single-file components, and I'm wondering what the developer experience is like without them.

🤷‍♂️ oh well...

@pmiazga , @Bawolff thanks for the warnings about the SkinVector class, we will take heed.
As mentioned above, the proposal was on Last Call until December 11, so I'm closing it out now and we're go ahead with the proposal (building desktop improvements inside Vector).
Lots of exciting work ahead!

Maybe we can even run the npm scripts in parallel to get them over with faster? I don't think the linters are interdependent.
NPM packages like concurrently can parallelize npm scripts (so can &, but this does it cross-platform) and that one has a --kill-others-on-fail option which returns a non-zero exit code if any of the tasks fail.

@nray @Jdlrobson Yeah, I don't see how we can avoid this bug without adding a class on page load. Removing the animation check & tests is fine, but we'll still have to add a class to the body.

yippee! looks fixed.

@alexhollender the change is live on the beta cluster. It'll go live whenever the train rolls around (I think it's this week).
https://drive.google.com/file/d/1GqQ8ZeXyxFoJP1SlfLrj0Py4e7E1Iyhr/view?usp=sharing
I think it looks pretty nice myself :D

@Volker_E Currently below every article title on Vector there's the tagline "From Wikipedia, the free encyclopedia". If we maintain that tagline, I don't think it's useful to basically repeat that line above the content as well.
We should consider whether we still want the tagline there, and if we do, whether we need alt-text on the logo or not.

I've created an epic to encompass the work needed for the new header: T240856

Although this task sets out to actually try and build a new "throwaway" header, I've identified some ground-work that has to happen before we can even begin building a new header:

I'm unable to reproduce on Chrome on Windows, but we have gotten reports of this issue sporadically.
Currently I'm seeing a disappearing icon on Mac Safari on the Wikimedia beta cluster. https://en.m.wikipedia.beta.wmflabs.org/wiki/TemplateUsageArticle392#
I also noticed this issue when using the VoiceOver screen-reader on iOS, in which icons disappear after the focus has been placed on them.

Hope that does it.

Since this is only a linting change and only adds comments, I figured it's ok to skip QA.

@Quiddity mentioned that the prototype doesn't do a good job of loading certain language specific templates, such as the French Wikipedia's infoboxes

@SpookyGhost8 what browser/OS is this occurring on?

We also had a conversation about DOM order during our offsite in regards to accessibility. My intuition says that rendering the content first, as Vector currently does, makes life easier for screen-readers & assistive tech, since they don't have to skip through the navigation to get to the content.

Currently in the Vector skin, the header HTML, (along with the sidebar & other navigation) are placed below the content. (The header is made to look like it is above the content with CSS).
My understanding is that this was done for performance purposes - so that page content loads first, as well as for accessibility reasons - so that page content is the first thing presented to screen-readers.

I tried to update the peer dependencies, but this led to the following error when building a binary with node-gyp :/ so I think a revert is in order here.

Since there's already a patch up for this task (thank you @Jdlrobson!) I think this can be estimated and moved to the code-review column.

Looks like this task has been thoroughly analyzed and followup conversations are planned, so this task can be resolved. Looking forward to the Modern Event Platform!

As this just affects print styles, I didn't see the harm in merging the proposed patch. Moving to design review in case @alexhollender has any comments on this. (Merged patch should be visible on the beta cluster).

@Jdlrobson yes that issue was addressed just after the branch cut last week, so it should appear solved soon.

As @Jdlrobson mentioned earlier, the Web Team intended to make a decision on this by October 31 🎃.
I've updated the task description with our decision under the heading "RFC Outcome". Instead of forking Vector as originally proposed, we will be implementing the Desktop Improvements project inside Vector. Every option has it's trade-offs, and after considering the points made in this discussion, we felt that working in Vector was the most pragmatic way forward.
Thanks to everyone who contributed to this discussion!

@Bawolff thanks for your comment. I agree that in an ideal world, a new skin would be the most sensible option. However, given the state of the skinning system, extension compatibility, gadget compatibility, community buy-in, etc. I don't think the ecosystem is in a state where an additional skin is maintainable. As you mention, the "current experience maintained in parallel" line in Proposal 2 recognizes that realistically, we can't get rid of the current Vector "experience" anytime soon.

I made one followup patch to fix an issue in non-amc mode with the labels.

A couple of weeks ago @santhosh reached out to me to show his side-project https://wikivue.netlify.com
(source code at https://gitlab.com/santhoshtr/wikivue/tree/master/src)

we (the Reader’s Web team) have been giving a lot more thought to the new-skin & update-vector proposals recently.

Thanks for confirming @EBernhardson, one of the key learning from this task is that if we're to change the search experience on desktop as part of the Desktop Refresh project, we should consult the Search Platform team beforehand because changes to the UI can impact your key metrics, that and any new UI should maintain compatibility with the SearchSatisfaction schema.