1380691 - Use the same tools and versions when processing static assets in different environments

Status: RESOLVED FIXED

(developer.mozilla.org Graveyard :: Code Cleanup, defect)

Description

[John Whitlock [:jwhitlock]]

What feature should be changed? Please provide the URL of the feature if possible.
==================================================================================
The static assets are processed by different tool chains depending on the environment.  They should use the same tools, at the same versions.  One good tool for doing this is package.json, to define top-level packages, and npm-shrinkwrap.json, to define exact versions of installed packages.

The current situation:

When processing assets inside a docker container, the versions in the Dockerfile [1] are used: cssmin@0.4.3, node-sass@4.3.0, uglify-js@2.4.13, etc.

When processing CSS using host-install gulp, the versions in package.json [2] and npm-shrinkwrap.json [3] are used: gulp-sass@3.1.0, node-sass@4.5.2

When processing assets in SCL3 deployments, system-installed packages are used: cssmin@0.4.3, node-sass@4.3.0, uglify-js@2.4.13, etc.  The default Django settings are set for SCL3 deployments. Changing requires installing new system packages.

In TravisCI, a script [4] installs cssmin@0.4.3 and uglify-js@2.4.13.

[1] https://github.com/mozilla/kuma/blob/master/Dockerfile-base
[2] https://github.com/mozilla/kuma/blob/master/package.json
[3] https://github.com/mozilla/kuma/blob/master/npm-shrinkwrap.json
[4] https://github.com/mozilla/kuma/blob/master/scripts/travis-install

What problems would this solve?
===============================
There is a slight difference in tool versions between the host-installed gulp process and other environments.

Changing tools and versions requires changing several files, including manual steps in SCL3.  This is error prone, and makes developers reluctant to upgrade and try new tools.

Who would use this?
===================
Back-end developers, SREs, and webops work together to install npm packages.  Front-end developers use them.

What would users see?
=====================
The same version of npm tools would be used in all environments. A single place and process would be used to update them.

What would users do? What would happen as a result?
===================================================
Front-end developers would have increased confidence that files generated with one process will be identical to files generated in another process.  Back-end devs would upgrade tools more frequently for feature and security updates.

Is there anything else we should know?
======================================
A similar process is used in SCL3 to install npm packages for KumaScript, and has been good for evolving that package.  Changes may be needed to the SCL3 configuration to allow settings the paths to locally-installed npm packages rather than globally-installed packages.

Comment 1

[John Whitlock [:jwhitlock]]

This was fixed in bug 1468491, as part of upgrading to node 8.