Before packaging for NPM, remove the "engines" section of package.json
to avoid unnecessary restrictions on node versions for projects that
simply depend on Shaka Player, but don't need to rebuild it. This is
accomplished with the clean-package tool:
https://github.com/roydukkey/clean-package
The "engines" section and its restrictions still make sense for Shaka
Player development, so it will not be removed from package.json in the
repo.
Closes#5243
This includes a temporary config file to bootstrap the workflow for
the master branch, whose commit and branch history is too confusing
for the tool to handle with defaults. After v3.4.0 is released from
the master branch, these configs can be deleted.
According to https://github.com/npm/npm-packlist/issues/24, a certain
release of NPM started ignoring files named "core" implicitly, which
broke the build system in our release packages starting with v2.5.11.
This works around the issue by asking NPM explicitly _not_ to ignore
that file.
Closes#2752
Change-Id: I7d9fb45abe6cd70e02fc4bb14a08126f93b4cc0a
This adds our first screenshot-based layout tests and the
infrastructure to use WebDriver for screenshots through Karma.
This new kind of test will be skipped in any non-WebDriver context.
There are many pieces to this system.
First, we update the Karma WebDriver launcher to a newly-released
version that lets us access the client spec object from the launcher.
Second, we build a Karma middleware plugin to respond to HTTP requests
from the tests. We handle /screenshot/isSupported and return a bool
so tests can be skipped on non-WebDriver launchers. We also handle
/screenshot/diff to take the screenshot and compare it to a known-good
version.
The screenshot is a full-page screenshot, since element screenshots
don't work consistently across all the browsers in our test lab. The
screenshot is then cropped to a rectangle specified in the request.
This rectangle is measured to match a specific element, so in
practice, we are screenshotting just one element.
Browsers use sub-pixel rendering, effectively rendering at a scale
larger than the "pixels" seen by JS. The screenshot comes in at this
scale, so the requested cropping rectangle is scaled to match, then
the cropped screenshot is scaled down to the JS-measured size.
Because of sub-pixel rendering, element offsets can be non-integer
numbers. Normally, Karma puts the tests in a iframe, above which is a
variable-height banner showing which devices are connected to Karma
and what state they are in. So this variation and the lack of integer
offsets means we can run into stability issues due to rounding errors.
To make offsets consistent and improve stability of the screenshots,
this banner is now disabled in our Karma config.
The cropping, scaling, and diffing of images is handled Karma-side by
a node module called Jimp.
Before we start the layout tests for UITextDisplayer, we use a node
module in the browser called fontfaceonload to wait for our web fonts
to be fully loaded. This module is a polyfill that polls on IE and
uses a standard API in modern browsers to wait for our font to load.
This is all wrapped into a new test util called waitForFont.
Screenshots are stored in test/test/assets/screenshots/ and are
organized into folders by platform and browser and named according to
an identifier specified by each test case. The new screenshot is
written to disk with the suffix "-new", and a diff image is written
with the suffix "-diff". When a test fails, we can review the changes
in a browser with test/test/assets/screenshots/review.html. The
known-good screenshots can be updated with the new tool
build/updateScreenshots.py.
Change-Id: Ib477fd3c459de466c6dc91e9a60d3e2579164b12
This also configures the package to compile at publish time, which
should enable cdnjs to auto-update the library.
Change-Id: Ib32ac1c44d11e10f344a2409caa800d7312c1996
Álvaro Velad Galván
Joey Parrish
Isaac Ramirez
Joey Parrish