Skip to content
Fast, drop-in replacement for Magento's Static Content Deploy (WIP)
TypeScript JavaScript PHP
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.
.circleci Add config for CircleCI Jul 18, 2019
bin Huge milestone: first single-locale working version of luma compiled Jul 20, 2019
scripts Start working on CLI + more unit test coverage Jun 28, 2019
src Add support for @import of a .less file without a file extension. Closes Jul 24, 2019
.editorconfig Initial Commit May 28, 2019
.gitignore Update readme Jul 23, 2019 Updates to CLI and unsupported features list Jul 11, 2019
package-lock.json Huge milestone: first single-locale working version of luma compiled Jul 20, 2019
package.json Huge milestone: first single-locale working version of luma compiled Jul 20, 2019
prettier-globs Initial Commit May 28, 2019
prettier.config.js Initial Commit May 28, 2019
tsconfig.json Initial Commit May 28, 2019


Fast, drop-in replacement for Magento's Static Content Deploy


For background on the motivations for the scd project, please see the original proposal.

How to use

This project is not quite ready yet, and many features from Magento core are not supported just yet. If you want to live on the bleeding edge, you can follow the developer instructions below.

How to work on scd

  1. Ensure you have a version of node.js locally that is >= v10.12.0
  2. Clone the repository
  3. In the root, run npm install
  4. Run npm test to verify you've set everything up properly. All tests are expected to pass

How to run against a store locally

  1. Run npm link in the root of this repository once. This will add the global scd command to your $PATH

You can now run scd in the root directory of any Magento 2 store locally.

What works for far?

Only one scenario has been tested and developed against so far. This is:

  • Stock store on 2.3-develop
  • Using Luma
  • Only targeting en_US

Things that have not been tested yet:

  • Translations (they're not even implemented, so they surely don't work)
  • adminhtml theme(s) (they might work, but I haven't tested)
  • Deploying multiple themes at once. It might work (untested), but they're currently processed serially

Should I use this for Production?

You're probably not going to listen to me, but I wouldn't just yet.

Unsupported Features


Design Goals

  • Favor speed over memory consumption always. Memory is cheap, time is not
  • (Except in rare cases) data structures passed between module boundaries should be limited to those that can be easily serialized to JSON. This keeps it possible to move modules to a worker or use caches for only certain tasks later.
  • Always favor optimizing code over caching
    • Only add caching in places where slow things cannot otherwise be sped up
    • Caches are always a bug farm in build tools
  • Thoroughly loggable/traceable
  • As much of the code base should be stateless as possible. Keep state confined to well-defined areas
  • Keep root path handling separate from relative path handling
    • Any persistent caching should work even when store is moved to another dir on disk or copied to another fs
  • Compiled/released version should be compatible with Windows, but only *nix compat is fine for building the project and running tests
You can’t perform that action at this time.