Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    David Manning
    @dlmanning
    Okay, I hear a lot of chatter about npm phasing out peer-deps altogether in an upcoming release
    Sam Richard
    @Snugug
    Oh really? Well then that's a no-go for that
    I had not heard that
    David Manning
    @dlmanning
    I know a couple of npm people, I'll check on what the current plan is
    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
    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
    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?