refactor npm run build:css

[Carreau]

It is ridiculously slow, and the step it takes are also ridiculous as:

• npm run build:css
  • call python setup.py css
    • that call jsdeps
      • that call npm install (to get bower)
      • that call npm run
        • and call bower install
  • then build the css by calling less.

Like really ? Asking the build the css invoke 3 different installation programs in 2 different languages. The build itself take a fraction of a second, for 2 files.

[takluyver]

We need some shell scripting, a Makefile, and a couple of scripts written in lolcode somewhere in that toolchain. How are we meant to be web 2.5 with only two languages?

[rgbkrk]

Wow that's painful.

I'm assuming this would look better:

• npm run build:css
  • Builds the CSS by calling less

I'm assuming this project would need to get off bower, switch to full npm usage, and be reliant on npm scripts.

[blink1073]

Getting off of bower would rely on better versions of requirejs and mathjax npm packages.

[blink1073]

As in, the requirejs package does not currently play well with webpack.

[takluyver]

We have told quite a few people to use python setup.py css js, so those should probably keep working, however it works internally.

[minrk]

setup css/js can call npm run build, but npm run x probably shouldn't call setup.py.

[minrk]

#1436 removes the js->python call.

I still wish that webpack, etc. (everything, really) used Makefile-style detection to determine if builds need to run again, because unnecessary webpack rebuilds take a really long time.

[blink1073]

Looking again, the npm packages for requirejs abd bower are self-contained, so they could be fetched via as npm packages and then served in-place or move the files to another location for serving.

[Carreau]

Thanks.

I still wish that webpack, etc. (everything, really) used Makefile-style detection to determine if builds need to run again, because unnecessary webpack rebuilds take a really long time.

Are you going to rewrite a javascript building tool ? But agree, even if not based on datetime at least invalidate only part of the build graph when content hash changes...