Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Sam Richard
    @Snugug
    Awesome. I can poke around too.
    David Manning
    @dlmanning
    I'm not familiar with node-sass-import-once
    Sam Richard
    @Snugug
    I just wrote it a couple of days ago
    It's an importer for node-sass (works on 2.x, better on 3.x) that restricts imports to only be imported once
    Allowing sub-modules to declare their own dependencies without fear of duplication
    David Manning
    @dlmanning
    Okay
    Sam Richard
    @Snugug
    I also added in a few niceties that have bee highly requested in Sass, like being able to do @import 'partials'; and it import partials/_index.scss, being able to import CSS files directly into Sass, and the ability to automatically search for common Bower patterns
    David Manning
    @dlmanning
    So that wouldn't be something that would go directly into node-sass?
    Sam Richard
    @Snugug
    My thinking basically is, if a user includes the importOnce option, we automatically pass it to node-sass's importer option, otherwise we keep that as undefined
    David Manning
    @dlmanning
    I feel a little worried about extending sass syntax in a gulp plugin
    Sam Richard
    @Snugug
    It's an importer for node-sass
    David Manning
    @dlmanning
    Alright, so it would just be a config option, basically
    Sam Richard
    @Snugug
    Exactly
    I've also got my eye on https://github.com/sass-eyeglass/eyeglass which is essentially the node-sass version of Ruby Sass's Compass
    David Manning
    @dlmanning
    Okay, we could look at making a node-sass 3.0 branch and trying it there
    Sam Richard
    @Snugug
    Yup, sounds good
    Luis Martins
    @lmartins
    Morning everyone, anxious to help wherever I can too. Thank you all for the awesome work.
    Luis Martins
    @lmartins
    Is there any plans to merge the node-sass v3 into development for testing?
    Sam Richard
    @Snugug
    We are going to create a new branch and work it out in there
    With some enhancements
    Daniel Sellers
    @designfrontier
    Does the v3 branch include better error messages?
    Sam Richard
    @Snugug
    @designfrontier We are not in charge of the error messages coming from Libsass
    All we can do is wrap what they provide, but we have made them a little easier to see
    Errors are clearly indicated with their line numbers and files highlighted in color
    Daniel Sellers
    @designfrontier
    @Snugug correct... but the default wrapping is pretty lame. I can throw together a pull request that formats it better this afternoon. Right now I am using onError to clean it up.
    Daniel Sellers
    @designfrontier
    oh wait... in what version is the cleaned up formatting? @Snugug didn't see the last part of your comment
    the version I am running seems to not have that... it just drops the gulp plugin error with no details about the sass error
    Sam Richard
    @Snugug
    @designfrontier https://github.com/dlmanning/gulp-sass/blob/2.x/index.js#L42
    I tried it with wrapping the line number and fie to the next line but it looked a little weird. I think the colors help out the legibility greatly
    We also have https://github.com/dlmanning/gulp-sass/blob/2.x/index.js#L63-L67 for a custom error reporter
    Resulting in https://github.com/dlmanning/gulp-sass/blob/2.x/README.md#basic-usage for error handling
    Daniel Sellers
    @designfrontier
    what
    Oh sweet! What is the timeline for 2.0 being published?
    Sam Richard
    @Snugug
    After Node Sass 3 is officially released
    Sam Richard
    @Snugug
    Actually @dlmanning did you give publish access to npm? If not, maybe we roll a beta release now for people to play with?
    David Manning
    @dlmanning
    @Snugug : For the moment I'm happy to publish to npm with an @beta tag when we're ready
    I was going to say we need to add back the option to called sass.renderSync
    Someone had a reasonable use case where it's quite a bit faster than the async version
    Sam Richard
    @Snugug
    I've got an idea
    David Manning
    @dlmanning
    yes?
    Sam Richard
    @Snugug
    Same model as jQuery, so defaults to async, but can choose to call sass.sync instead
    I'll mock it up tonight
    David Manning
    @dlmanning
    Yeah, that's basically how it worked before
    There was an option to pass in
    Sam Richard
    @Snugug
    Yah, but I don't want an option
    David Manning
    @dlmanning
    Oh, because you don't like the idea of a function sometimes behaving synchronously and sometimes asynchronously?
    Sam Richard
    @Snugug
    Yah, kinda. Note that I want it to be more explicit than a hashed option. I'd like to keep the options hash as clear as possible and something we can pass straight through
    Don't want to conflate rendering options as specified by the compiler with ours
    David Manning
    @dlmanning
    That makes sense to me
    Sam Richard
    @Snugug
    Cool. I just got in. I'm going to write this PR up