-
Notifications
You must be signed in to change notification settings - Fork 96
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
Added support for sourcesContent and update to node-sass v2.0.1 #43
Added support for sourcesContent and update to node-sass v2.0.1 #43
Conversation
Nice work. Is there anything blocking this from merging? node-sass@2.0.0-beta is needed to for CentOS6.4 / gcc 4.4.7. See: sass/node-sass#517 |
I believe there's a beta version of broccoli-sass for this already, but if not @joliss should be able to release one |
Would love to see this getting merged. Otherwise broccoli-sass is not working with iojs. |
@joliss is looking into this now, hopefully should have a release soon. |
If I try to use |
I'd guess that you would just provide |
Okay that's fixed now @joliss. |
@aexmachina 2.0.0 final is out too now! https://github.com/sass/node-sass/releases/tag/v2.0.0 |
Awesome, great work. I'd push an update, but the install fails:
|
@joliss node-sass 2.0.0 is released now. I've updated the PR and this is working well for us now. Would you please merge this and publish a new version of broccoli-sass. I know there's a few people who would like to use it. |
Guys right now it's impossible to run |
@Ghostavio you can just install |
Yes unfortunately I don't have permission to publish the npm module. On Sat, 14 Feb 2015 08:12 Markus Padourek notifications@github.com wrote:
|
You are right it should produce map-file-content xor embedded-map-content. I have added that to sass/libsass#885 with NEW tag (//cc @xzyfer). Unfortunately, @aexmachina's suggestion does not work because (of that flakiness described in that LibSass issue and) without setting Having said that, node-sass does not write to anything to file system (except for the CLI usage). Consider this implementation of node-sass: // this is node interactive console
require('node-sass').info(); // 'node-sass version: 2.0.1\nlibsass version: 3.1.0'
require('node-sass').render({
data: 'a{b:c}', // OR you can use file: /path/to/file.scss,
// but in case of `data` AND `file`, `data` will take precedence.
// more on this is described here:
// https://github.com/sass/node-sass-middleware/issues/23#issuecomment-74374504
outFile: 'my-prospective-output.css', // again see sass/libsass#885
// it should 'only' be necessary when
// separate source-maps (.map) is required.
// if you are curious why it is necessary at all
// (since node-sass is not dealing with IO)
// see https://github.com/sass/node-sass/issues/591
sourceMap: true,
sourceMapEmbed: true,
success: function(result) {
console.log(result); // here result.css has embedded map
// and result.map has undesired source-map
}
}); For now, what you guys can probably do in your function myCallback(result) {
if(result.map && !myOptions.sourceMapEmbed) {
// invoke IO op to write .map file
}
// do more with result obj
}
var myOptions = {
success: myCallback,
// other options
};
require('node-sass').render(myOptions); |
@am11, notwithstanding the node-sass issue you posted, I'm not aware of any issue here. This PR will write the source map to filesystem if the We could provide a workaround for the node-sass issue but I'd prefer to keep workarounds out of broccoli-sass and instead get the issue resolved in node-sass. |
@aexmachina, this LibSass behaviour is a by design. Node-Sass is only a relay wrapper, it should not alter or supplement the decisions made by LibSass. So in your code, you can probably consider changing: if(this.sassOptions.sourceMap) { to: if(this.sassOptions.sourceMap && !this.sassOptions.sourceMapEmbed) { And if you think about it, there is no decent work around for it in node-sass either; and doing something very strange like 'unsetting' the |
@am11, I do appreciate your input on this, but I'm afraid that your communication is quite unclear. Let me be very clear:
In the same way that node-sass should be a thin wrapper around libsass, broccoli-sass should be a thin wrapper around node-sass, and not introduce different semantics around options. The issue with |
@aexmachina, please specify which part is not clear to you? As of node-sass v2.0.1, you can use the aforementioned condition in broccoli-sass because in this PR you are writing the map file to file-system. |
|
Yes; because in this PR you added that condition in success callback.
I am only suggesting to alter your condition like this.
If they will address that issue, that will not be considered as a fix, but it will be a change in behaviour in future version of LibSass. The current behaviour is not 'flawed' per se but there is a room for improvement. |
Okay cool. The problem with your suggested change is that we would then have different semantics to libsass, so I'd like to wait to see what they want to do first. Furthermore, I think that |
Brilliant. 👍 |
Excellent! We made it 👍 |
👍 |
@joliss would you like to merge this, please? |
Just for the record (in case you don't already know) I think @joliss is now working off a timebox where she dedicates a particular day a week to her Broccoli activities. I expect she will get around to this on her next allocated day so give it a week and check back 😉 |
Temporary fix due to using node v0.12. Once joliss/broccoli-sass#43 has been merged, this can be removed.
I'm closing this in favor of 6e600fe. Once we have the path handling kinks ironed out (sass/libsass#908), we can hopefully bring back source map support. |
No description provided.