search

atomify / atomify

Atomic web development - Combining the power of npm, Browserify, Rework and more to build small, fully encapsulated client side modules
MIT License
400 stars 28 forks source link

live reload server doesn't watch the css entry point for changes (it does watch the dependencies -> @import "dependency") #73

Open borisirota opened 9 years ago

borisirota commented 9 years ago

Test case:

  1. download boilerplate-node-module-angular
  2. npm install
  3. npm start

Check out the build script inside package.json and see that I'm passing the lib/index.css as entry point to atomify-css.

Trying to update and save lib/index.css does nothing.

In order to solve it, it is necessary to pass the file path as patterns to the live reload -> replace the build script line inside package.json with this line: "build": "npm run index:build -s && atomify -j [ -e lib/index.js --alias /assets/bundle.js --debug --watch --assets [ --dest build/assets --prefix /assets/ --retainName ] ] -c [ -e lib/index.css --alias /assets/bundle.css -o build/assets/bundle.css --assets [ --dest build/assets --prefix /assets/ --retainName ] ] -s [ --open --path / --lr [ --patterns lib/index.css --patterns lib/index.css --port 9999 ] --st [ --path build/ --index index.html --no-cache ] ]",

You can see that now --patterns is being passed to --lr (the duplication is because the code expects it to be array if exists -> BTW, why there is a need to watch args.js.output and args.css.output if the source files are being watched ?).

Isn't the watch of the css entry point suppose to be out of the box ? Am I missing something ?

Thanks

serapath commented 9 years ago

For me, the css watch did not work, so i added it. I'm normally, just if you are interested, i made some slides to present how to do components with atomify and theme them (I figured, the atomify-css variables are unnecessary).

I'm using strict BEM css conventions in order to strictly namespace EVERYTHING in css, so that under no circumstances in any kind of environment, there is a chance of NOT breaking the cascade. I do that, to simulate "local scope" in css. It's already best practice in javascript to do that.

If you'd like to give some feedback on whether it makes sense or how to improve it, that would be welcome, otherwise, dont bother :-) See: https://github.com/atomify/atomify-examples/pull/5 or better: http://serapath.github.io/atomify/#/

borisirota commented 9 years ago

@serapath I see what you added but without turning the css watch on (your addition), the watch does work but only for the imports (without the entry file) -> gaze adds the imports to be watched.

As a result, if turning the css watch mode, any change in the imports will be notified twice (not a big deal but it seems that the watch is already implemented (if I'm not missing something) and needs a small addition of the css entry point (see solutions)).

Solutions:

  1. Changing args.css.output to be args.css.entry (or adding in order not to conflict with the css watch mode you added) so gaze will trigger the live reload + concat the css path as well if patterns exist.
  2. Making the prefilter (inside atomify-css) to be called on the css entry point as well (not sure how this is work) and then gaze will be notified.
  3. Passing --patterns lib/index.css --patterns lib/index.css parameters to live reload - manual solution similar to the out of the box solution in 1 - Currently thats what I'm doing.

Now I understand why you moved the server to be under if css output provided (because this is part of the explicit css watch mode), but it isn't necessary to provide a css output in development mode (its also possible to use a default path like in the js case but then imports will be notified twice). With one of the described solutions the css watch will work without turning on the explicit watch mode and the css will be generated on the fly :)

Later I'll watch the links :)