-
Notifications
You must be signed in to change notification settings - Fork 98
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
Support autoprefixer in pipeline #45
Comments
+1 |
Alternatively, pleeease is also worth looking at |
Thanks. Personally, I would on board with having Autoprefixer, and I think it fits well with Harp’s philosophy as long as it’s not configurable. We would need a post-processing step for all CSS, though, which doesn’t exist right now, but would also be nice to place to fix #30 Any chance you’d be interested in submitting a pull request for it if @sintaxi is also interested? |
I think you guys have the right idea. The question I have is should this be the responsibility of Harp or of a Sass/Less/Stylus library? If so, is there going to be situations people do not want the auto-prefix behaviour? |
I regret to say I don't have the expertise to plug this in and submit a PR myself. I can say that autoprefixer runs on a framework called PostCSS, which is by the same author. Also it's independent of Stylus/LESS/Sass, since it is a discrete second step, usually needing a CSS output file to work from, though it's also apparently been made to work with a streaming style workflow as a gulp plugin. It does also have configuration questions: namely, which browsers (how far back) to support with the added prefixes, and also whether to process source-maps or not. So I don't know if that's perhaps contrary to the philosophy of Harp. Incidentally: do source-maps get handled with Harp? I know that LESS and libsass both can output them; not sure about Stylus. Anyway the reason I asked about integrating it in the pipeline, is that I've found that the main application which is post-processing and live-reloading needs to be aware of the autoprefixer step, or the workflow (mainly the live-reloading) is thrown off. In the case of Harp even more so I guess, due to the css source being entirely hidden—otherwise I'd say let's just have a way to hook it up with Grunt or something. |
+1 Great work with harp, very much enjoying it so far :) |
Popped a PR in for autoprefixer here: #57 |
My guess is yes, but, I would definitely love to see this behavior in harp. So, maybe it could be triggered in the pipeline just like the mime types? If you don't want it, nothing to be done and keeping using harp as you have been, but, if you do just add the extension prefix and it's there.
|
I really don't think there's a good reason not to use autoprefixer. Given On 8 September 2014 05:41, Michael Russell notifications@github.com wrote:
|
v0.9.0 of Terraform is actually already tagged and comes with @geelen’s integration of Autoprefixer, the next version of Harp will include it. We decided the situations where people wanted to opt-out of automatic vendor prefixing would be so rare that it fit under the convention over configuration philosophy Harp uses. In the next version of Harp, if you write LESS, Sass, or Stylus, you CSS will be vendor prefixed, and if you write CSS, it won’t be. Edit I had this tab open all evening, so I didin’t see @geelen’s comment until after I posted. But basically, that! |
Awesome and agreed, didn't realize it had already been merged... Viewing the linked issue I see that now :) Was just giving some additional thoughts if it were still being debated, but, thankfully it's not! |
autoprefixer is becoming a standard part of CSS preprocessing workflow. Would it be possible to integrate it in to the Harp.js pipeline?
Also: currently the grunt-based node-sass and autoprefixer plugins preserve source maps; but the gulp-based ones do not. It seems it's an architectural issue. I wonder what the implications for this are in Harp?
The text was updated successfully, but these errors were encountered: