Upgrade JSDoc from v3.4.3 to 3.5.5:
- v3.5.0 JSDoc can parse any JavaScript that is supported by Babel
compiler.
- v3.5.1 fixes an incompatibility bug in Node.js < v5.10.0
- v3.5.5 fixes an incompatibility bug in Node.js v8.5.0
Prior to this change, object shorthand caused the following errors:
jsdoc -c jsdoc.json
fs.js:1979
binding.copyFile(src, dest, flags);
^
Error: EISDIR: illegal operation on a directory, copyfile '/home/stephen/dev/wmf/vagrant2/mediawiki/extensions/Popups/node_modules/jsdoc/templates/default/static/fonts/OpenSans-Bold-webfont.eot' -> 'doc/autogenerated/fonts'
at Object.fs.copyFileSync (fs.js:1979:11)
at /home/stephen/dev/wmf/vagrant2/mediawiki/extensions/Popups/node_modules/jsdoc/templates/default/publish.js:471:12
at Array.forEach (<anonymous>)
at Object.exports.publish (/home/stephen/dev/wmf/vagrant2/mediawiki/extensions/Popups/node_modules/jsdoc/templates/default/publish.js:468:17)
at Object.module.exports.cli.generateDocs (/home/stephen/dev/wmf/vagrant2/mediawiki/extensions/Popups/node_modules/jsdoc/cli.js:430:39)
at Object.module.exports.cli.processParseResults (/home/stephen/dev/wmf/vagrant2/mediawiki/extensions/Popups/node_modules/jsdoc/cli.js:383:20)
at module.exports.cli.main (/home/stephen/dev/wmf/vagrant2/mediawiki/extensions/Popups/node_modules/jsdoc/cli.js:227:14)
at Object.module.exports.cli.runCommand (/home/stephen/dev/wmf/vagrant2/mediawiki/extensions/Popups/node_modules/jsdoc/cli.js:180:5)
at /home/stephen/dev/wmf/vagrant2/mediawiki/extensions/Popups/node_modules/jsdoc/jsdoc.js:103:9
at Object.<anonymous> (/home/stephen/dev/wmf/vagrant2/mediawiki/extensions/Popups/node_modules/jsdoc/jsdoc.js:104:3)
at Module._compile (module.js:662:30)
at Object.Module._extensions..js (module.js:673:10)
at Module.load (module.js:575:32)
at tryModuleLoad (module.js:515:12)
at Function.Module._load (module.js:507:3)
at Function.Module.runMain (module.js:703:10)
https://github.com/jsdoc3/jsdoc/releases/tag/3.5.0https://github.com/jsdoc3/jsdoc/releases/tag/3.5.1https://github.com/jsdoc3/jsdoc/releases/tag/3.5.2https://github.com/jsdoc3/jsdoc/releases/tag/3.5.3https://github.com/jsdoc3/jsdoc/releases/tag/3.5.4https://github.com/jsdoc3/jsdoc/releases/tag/3.5.5
Bug: T165036
Change-Id: Ic7a22b6992d45fa0ea3d011a9ad5200d7cc73b80
CI doesn't use a version of NPM that reads package-lock files which
seems to break some build product diff checks.
Bug: T165036
Change-Id: I29383c1a5c1f7f102fe458ac778adc3bf264c9fd
Replace Mustache.js templates with template literals. An effort was made
to minimize additional refactoring, so feel free to ask for more but it
ain't coming in this PS.
Bug: T165036
Change-Id: I4a6a1d93a2922c3a9ef3ae93c47da17a35c644f0
Enable the Babel transpiler so that ES6 template literals,
destructuring, and arrow functions can be used in production.
"last n versions" syntax was not used so that builds are more
reproducible.
Bug: T165036
Change-Id: I553b6d14cc368c7b4366f68d13038c3d505f5429
Webpack has some simple but useful options for specifying performance
limits. This patch enables asset and entry point (+ all dependencies)
filesize requirements for production builds. This helps us track
minified but uncompressed filesizes which are reported by
mw.loader.inspect() (including CSS).
https://webpack.js.org/configuration/performance/
Bug: T165036
Change-Id: I331ff34f50270be2912fd8cef5219cafc6957e80
Various tweaks were made in Ibe212721807d3698dc45ef46b2dbde15ca9d2f70
to get the browser tests to pass. Many of them were unnecessary.
Change-Id: I47ac37512da38a33f4b3b919cc412b79231b0324
This helps with readability. Given its auto-generated it shouldn't
be necessary to scrutinise it during code review.
Change-Id: I0ae3bfef4f5fac399dd094398850ea7d73906045
- Add SVG Inline Loader for Webpack. This allows SVG files to be
imported.
- Update the Webpack and test configurations to use the new loader.
- Scope the ESLint rules down to just JavaScript files so that linting
isn't attempted on the SVG.
Bug: T165036
Change-Id: I00bccff4c3167975c19d577be6343dcaca7ddb2d
Creating a different page preview for disambiguation pages.
This patch:
- modifies the Preview model to accept a new 'type' property
- modifies the Restbase Gateway to pass the 'type' prop to the Preview model
- creates a new template to accept both generic/disambig previews
- modifies the renderer to render the new template
- generates icons for new template through resource loader
- adds new i18n strings
- modifies event-logging "preview seen" event to send new "disambiguation" previewType
- updates event logging schema version
- adds tests for Preview model and renderer for new preview type
- does way too much? yes, yes it does.
Bug: T168392
Change-Id: Idc936cc3eabbdd99a3d98f43c66b4cdbb7d24917
Add example for developing with a local copy of the Mobile Content
Service. Also: make tabs consistent with the rest of the repo.
Change-Id: I4cfb562c18c12df828e84602d01514c8c3cc20e6
Instead load it via mw.loader.using
We retain the module name ext.popups as this will be present
in cached HTML, however now it will load the bulk of the code
inside ext.popups.main
Bug: T176211
Change-Id: Ibe212721807d3698dc45ef46b2dbde15ca9d2f70
Allow developers to use different endpoints for summaries
= developer happiness
This is useful for the following use cases:
* A developer wants to test against a production endpoint via
CORS
* A developer has setup an API where REST is hosted elsewhere
e.g. http://localhost:6927/en.wikipedia.org/v1/
* A user wants to create their own REST summary compatible
endpoint
* A wiki e.g. wikidata wants to use a different endpoint which is compatible
with the summary endpoint.
We are unlikely to use it ourselves on Wikimedia wikis (the
default should suffice) but this will be a powerful tool for
When not configured this will continue to work as per normal
Change-Id: I8a7e12fbc43cddbac678e0d7b81d1e877b747b22
Stripping parentheticals were designed specifically for working around
issues with content inside wikimedia wikis and error prone.
This problem for wikimedia wikis is solved by the mobile content
service.
Given we have no intentions to use the MediaWiki API for summaries.
They are not necessarily useful to third parties and it makes little
sense to maintain them (a third party can configure their own API or
use their own REST endpoint if they really do need them).
Bug: T189042
Change-Id: I2729dc9f172af0afee1c6f0cd563c556b4ae0aeb
When the diff test fails, don't dump 40k characters to console. Just
report that the failure occurred.
Change-Id: I1cc31fcdebe3e1097ed9e80dfbe3fb6e0dfc34b2
SPDX released version 3 of their license list (<https://spdx.org/licenses/>),
which changed the FSF licenses to explicitly end in -only or -or-later
instead of relying on an easy to miss + symbol.
Bug: T183858
Change-Id: If21be3dd6d81dbeb30911bbe3be29e20b55bf6da
These are now taken care of by the Mobile-Content-Service's
summary endpoint and no longer needed here!
They are actually breaking certain previews so time for these
to go!
Bug: T183833
Change-Id: Icd2a21127c2f5881943564eca4df6bed3c15e223
Specifically, clarify why the timestamp property is merged into the data
bag that represents the event when it is.
Change-Id: I184de734e66490fc728a4f9c2f84bf0765aeed08
This change updates the schema and begins to log
additional information such as source_namespace, id
and title. This information is provided inside the
boot action.
Additional changes:
* Allow camel case in bundle artifact
Bug: T184793
Bug: T186728
Change-Id: I425ffecc018bef2958d0dfe957a40a065e3e6c56
Clarify why we don't have source maps in production and the interaction
with ResourceLoader's production mode, and reference phab task.
Bug: T188081
Change-Id: I4c5f60585429792ee3047268ad44449ab47fcff4
Don't assume that thumbnail URLs contain a dimension delimiter of "px-".
Previously, thumbnail URLs always contained the width. e.g.:
https://upload.wikimedia.org/wikipedia/commons/a/aa/100px-Red_Giant_Earth_warm.jpg
However, thumbnail URLs that actually point to the original are not
sizable:
https://upload.wikimedia.org/wikipedia/commons/a/aa/Red_Giant_Earth_warm.jpg
These are provided, for example, when the thumbnail size requested is
larger than the original. There was code designed to handle this
scenario but it only applies when RESTBase and page preview thumbnail
sizes happen to be in sync. In other words, if RESTBase requests a large
thumbnail on behalf of page previews, and page previews only requested a
small thumbnail, the original may be unexpectedly provided. A
conditional is introduced in this patch to verify that "px-" is actually
detected. If it is not present, the original is used.
Bug: T187955
Change-Id: If4e29dd870aecd6d461cc8203f6576d1bb8844f2
