-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integrate preprocessor triggers #2
Comments
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"
} |
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.
|
yeah, i want to change the way this work which would play into that suggestion. Currently the
|
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.
The text was updated successfully, but these errors were encountered: