Feature: Provide included files

[jhnns]

Hi, this is my pull request as discussed in #279. Please note that this pull request is not finished yet, see below.

I was working on this feature the past days when I realized that the code would get messier if I'd just pass another argument to bindings.render() (which has already seven arguments). Additionally I found it hard to grasp with optional arguments. That's why I decided to refactor the binding so it accesses the options object via property names instead of array indices.

Furthermore I noticed that the newly introduced renderFile (#285) doesn't normalize the passed-in options. Since this doesn't seem to be intended to me I decided to normalize them too.

As you can see I just refactored the code without touching the tests. Now all tests are running again, so this is currently save to merge back into the master (to prevent merge conflicts). Just wanted to get early feedback if you're ok with my refactoring.

Could you also check the C-code because I'm not an experienced C-programmer and might have missed something.

[andrew]

This is looking really nice, I'm not going to have chance to properly review for a few days but maybe @nschonni or @LaurentGoderre can weigh in as well.

[nschonni]

👍 I like normalizing the options in one place.

[nschonni]

Tagging this as a 0.9 since it will require a full set of new binaries

[jhnns]

Ok, all tests are running and the pull-request is ready for review. The stats-object now looks like this:

{
    entry: "path/to/entry.scss",    // or just "data" if the source was not a file
    start: 10000000,                // timestamp
    end:   10000001,
    duration: 1,                    // end - start
    includedFiles: [ ... ],         // absolute paths to all related scss files
    sourceMap: "..."                // the source map string or null
}

Check out test/stats_spec.js for details.

I've put the scssStr into an own module because I needed the same string, too. That's why it looks like I've changed the tests. Actually I didn't change them, I just added two assertions (see line comments). Additionally I've refactored the code where appriopiate so node-sass behaves the same way whether we're using the cli, render(), renderSync() or renderFile(). Could you run this pull-request against an existing project to make sure there's no breaking change which wasn't caught by a test?

If you're ok with these changes I'll add them to the readme and the pull-request is ready to merge.

One thing I noticed: The sourceComments and sourceMap sanitization is done inside of lib/cli.js and renderFile(). The cli should use renderFile() and all sourceMap related stuff should be done at one place. But this is not part of this pull-request.

[keithamus]

Needs rebasing, if you could please be so kind @jhnns

[jhnns]

I've rebased the pull-request. The tests are still running on node 0.10, but they break on node 0.11.11 due to latest changes in node core.

According to the nan changelog we need to update nan to 1.0.0 in order to be compatible with node 0.11.13. But imho this should be done in a separate pull-request. What do you think?

Can you review the pull-request and merge?

[nschonni]

According to the nan changelog we need to update nan to 1.0.0 in order to be compatible with node 0.11.13. But imho this should be done in a separate pull-request. What do you think?

💯 a separate PR makes sense

Can you review the pull-request and merge?

@andrew do you want to do a new release, I tagged this as 0.9 since the API is changing but maybe you're ok with this in a point release since it is under v1

[andrew]

Yeah I don't mind a new point release, will try and get a new release out today with this in.

[jhnns]

Yay! 👍

[andrew]

Just trying to work out why the tests are passing on travis but not on my mac, then we'll need some new binaries, cc @LaurentGoderre

[andrew]

I don't have the time to debug this today, but this isn't working at all on the mac, returning undefined:0 a lot and then throwing TypeError: undefined is not a function, I guess it's a change in the C++ code somewhere.

[jhnns]

Do you have a stack trace?

[andrew]

It doesn't thrown any kind of stack trace, is there a flag I need to pass or debugger I need to use?

[jhnns]

No, i don't know any flag. Can you identify which function is undefined when TypeError: undefined is not a function is thrown?

Unfortunately I don't have a mac and hence can't reproduce it.

[jhnns]

Could you check if #302 fixes this problem?

[andrew]

@jhnns here's the failing test output: https://gist.github.com/andrew/387ac9d2350d4b3d9009

[andrew]

Sorry ignore all that @jhnns, turns out I wasn't correctly rebuilding the binary, it's all good now.

Will get a new release out once we have all updated binaries ready in https://github.com/andrew/node-sass-binaries

[jtangelder]

I got the same issues with undefined is not a function on my osx machine, how do i do a rebuild? I've followed the steps on https://github.com/andrew/node-sass#rebuilding-binaries but no luck