There is no plan to create a npm package. All shared code should be in mediawiki/core.
Apologies for '../../../../../', it's caused by my lack of JavaScript experience. I am sure we can get rid of it (with some help from more experienced JavaScript developers) without creating a npm package.
Why not?
The code can still live in mediawiki/core inside package.json as a versioned dependency. It also means extensions can share that code easily.
This is what that would look like:
This is no different from how we did mediawiki-selenium releases in Ruby?.
Neater, no?
One of the major differences between Ruby and Node frameworks is the way we implemented sharing code. I see that we have never properly documented and/or explained it. Both approaches have advantages and disadvantages. I guess I need to document it properly. Tracked in T182692.
@Jdlrobson I support publishing these files from mediawiki/core as a package on npmjs.org. This allows much easier use by extensions and also avoids much complexity in future updates. In the current state it is impossible to make breaking changes to the page objects in mediawiki/core without either breaking extension tests, or having to update all tests in a Depends-On commit that needs to be merged at the same time. That's an anti-pattern we first ran into when we had only a single version of JSHint installed on Jenkins. We learned from that mistake and should not make it again.
Publishing it as a package means we can remove or change parts of the page object interface over time, without requiring a large-scale migration each time.
@ZFilipin (WMF) I agree we should continue to maintain these files in the mediawiki/core repository. I recommend adding a the package.json inside the directory where these files are maintained. Then, when it is time to make a release, you just run npm publish on a clean master branch.
