Integrate preprocessor triggers

[liambrownweb]

Toying with an idea, let me know what you think.

Currently I'm using Stylus, node-watch, and electron-css-reload in conjunction with a Node script I built to automate (p)reprocessing and reloading of stylesheets. The results: my colleagues and I have an easily managed hierarchy of Stylus scripts, we keep our hands clean from any raw CSS, and our process for style changes is actually better than using the built-in development tools in Chromium. I'm thinking it might make sense to fold the external functionality into this module; in addition to watching a file and its dependencies for changes to trigger an incremental reload, it could call the external preprocessor to rebuild the stylesheets. Stylus was my first choice, but I think it would be practical to avoid tight coupling and encourage the development of interfaces for other preprocessors too.

I realize this may represent unwanted scope-creep, but if you like it, I can prototype an integration on my separate project and submit a PR once I've verified a working state in my dev environments.

[dperrymorrow]

yeah i have toyed with the idea as well, I use stylus as well, but i feel that if we went down this route, we would have to support all the preprocessors less, stylus, scss ect...

my workflow is just having a npm script to compile stylus on change, and I like how simple that is rather than using another build tool

these are my typical npm scripts for a given electron project

scripts": {
    "stylus": "node_modules/stylus/bin/stylus --include-css -w frontend/windows/**/*.styl -I node_modules",
    "start:dev": "NODE_ENV=development electron .",
    "start:prod": "NODE_ENV=production electron .",
    "watch": "onchange './**/*.js' './**/*.html' './**/*.json' -i -- npm run start:dev"
  }

[liambrownweb]

I agree that keeping up on all the preprocessors could be a real headache, particularly if users weren't inclined to write their own interfaces. What about a user-specified callback that's triggered whenever a watched dependency changes? That's a very short rewrite and it doesn't alter the project scope.

[dperrymorrow]

yeah, i want to change the way this work which would play into that suggestion. Currently the DOM is scraped for css links and then those files are watched, this is not great for two reasons,

• its overly complicated, why not just pass in the dir of your css to watch
• it does not automatically detect dependancies of that linked css file changing, thus the hacky data-source="" workaround