In T272879#7161511, @Jdlrobson wrote:

Well ... Starting in Storybook 6.3, you can use Vite to build your Storybook

Note that links cannot be list items at the same time though (an element can only have one role)

In T284782#7150535, @Catrope wrote:

Point 2: the ExtendedVue thing doesn't look pretty and isn't helpful in the view that you showed, but it does enable TypeScript to know which props and methods exist and what their types/signatures are. This is helpful because if you do need to call a method on a component (not super common, but it happens), TypeScript will type check your method call. So I would advocate for keeping that.

To illustrate what that looks like in practice: if I have <wvui-options-menu ref="menu" /> in my template, then in JS I can do ( this.$refs.menu as InstanceOf<typeof WvuiOptionsMenu> ).handleKeyboardEvent( event ), and the IDE will show me the method documentation for that method, and TypeScript will type check the parameters and return value. You don't get this if everything is just a generic VueConstructor.

@mwilliams Adding the assessment filter to all tabs should be simple. There may be more searches that come back without results in these tabs but I don't see that as a problem.

I've created a dedicated task for some of the typing improvements I mentioned above here: T284782

Based on the stack trace, this looks to be related to the new OGV.js shim we started using; it's something related to TimedMediaHandler or VideoJS most likely.

Is this task still necessary if we can adopt a front-end build step that supports tree-shaking? In that case, consuming applications would just run the build step to ensure that only relevant components get included in their respective payloads.

@Krinkle both work-arounds you mention (using a wrapper file and limiting the change to packageFiles) sound workable to me. My motivation here is to ensure that any bundled modules we generate with newer build tools (Rollup/Vite/etc) are usable in ResourceLoader without too much additional effort. Existing 3rd-party libraries can continue to be handled the way they are now.

It seems clear that we want to use Typescript as we move forward with a shared component library. But there is still the question of the best way to use Typescript.

A couple of thoughts on what this could contain:

In T272879#7135214, @Catrope wrote:

Sounds good to me. But it might be nice to have the option of running a local Storybook, because some of the stories do exist for testing purposes, and I don't think we want to duplicate them all in demo pages. The basic story for every component also provides controls for tweaking all the props, which can be handy for testing while developing.

In T272879#7134971, @Jdlrobson wrote:

One thing I did wonder, if we are concerned about using storybook for code that doesn't run on our production wikis, but haven't explored, is whether it would make sense to have a single storybook repo for all our extensions, skins inside core or a separate extension.

In T284105#7127332, @Jdforrester-WMF wrote:

For OOUI, we deemed breaking changes to be those that changed the programmatic API or changed environmental requirements (//e.g. dropping Node 6 compatibility). Changes to the output CSS/DOM weren't considered part of our contract, so they didn't count as breaking changes.

Each breaking change release was announced in an e-mail to wikitech-l, and planned deprecations where possible were made and announced in the previous breaking change. For example, if we were replacing the method doX(), in version 0.X.Y we'd tag it as deprecated and document the replacement if appropriate. This would be noted in the release e-mail for 0.X+1.0. It would be removed in 0.X+2.0.

This might be a bit heavy-weight whilst you're still in active early development, however.

Quick update on this: I've opened a patch that ports WVUI over to Rollup for builds. So far here's what's working:

@thcipriani that's correct – I just need access to do the occasional backport and config deploy, I wasn't sure what the exact name for that group was supposed to be. Thanks!

Thanks, @thcipriani! I just opened a request ticket here to request shell access: T283541. Let me know if you need anything else!

It's going to be some time before we are able to re-write the front-end of this extension to remove all OOUI dependencies; this may happen if we port it over to a new WMF component library at some point. Closing for now.

@Etonkovidova – that is the correct param, but the patch was updated to include some config variables that likely need to be set on Beta and Production commons before this feature will work. I'll see about making sure this happens some time soon.

Updated some docs on https://www.mediawiki.org/wiki/Extension:TimedMediaHandler/VideoJS_Player#Usage so that others can more easily integrate Video.js and Ogv.js the same way.

Bumping this task to the main team board. @brion do you know anything about IE support for various video formats?

Current status on Beta commons:

This will need some testing in production (or Beta) once the new MediaSearch extension is enabled and publicly visible (may not happen for another week or two).

Ok, success! I'll upload a patch shortly. For posterity, the problem was that some extra configuration is needed to get the modules for videojs and ogvjs working together. The complete player initialization code looks like this:

Pretty sure this error is the result of some unsupported gadget or user script. I am unable to repro locally.

In T281145#7064299, @Jdlrobson wrote:

Chatted to @egardner and the above error is likely limited to commons so not likely to be an issue tomorrow.

@Etonkovidova this patch (like most patches going forward) was applied to the stand-alone MediaSearch extension version of this code – as opposed to the code that lives inside of WikibaseMediaInfo.

@Krinkle fair enough – I agree that ResourceLoader currently gives us most of the benefits that <script type="module"> would already, with greater backwards-compatibility. However, I do think it's good to keep an eye on the evolving state of the web here. There may be a time when we want to do less of this work ourselves and rely more on built-in browser functionality.

Invalid search queries and bad type params have been addressed at this point. I'll open a separate patch to try and deal with bad values for search filters.

In T281781#7055354, @Catrope wrote:

developers will benefit from better IDE tooling and will be able to write code in a more standardized way

What do you mean by this exactly? If you mean import and export, then I think there would be additional challenges in getting those to work/coexist with ResourceLoader. Are there other language features that are only available when type="module" is used?

@MarkTraceur, @dr0ptp4kt, and I chatted today about trying to unblock this task. I'm going to spend some time on a spike to see if I can apply the OGVJS shim to the "beta" VideoJs player that we are using in order to support OGG/WEBP playback in Desktop Safari in the same manner that we're currently doing for the legacy video player used on Commons File pages.

In T278509#7043447, @AnneT wrote:

I've been thinking about this some more and it raises a major question that we should answer early on in this process: when do we make a component more complex, and when do we create a new component?

I generally tend to support additional, separate components for the following reasons:

• It keeps components simpler, which benefits library authors (easier to write code iteratively and maintain code) and users (fewer props/etc. to keep track of per component)
• It makes components' purposes clearer to the library user

Mentioned this at today's Front-End Standards Group meeting, but I think this problem would be a good candidate for the new Technical Decision Making Process because it cuts across the concerns of several different teams. This process already includes a framework for evaluating different possible solutions (including the "solution" of leaving the current status quo in place).