-
Notifications
You must be signed in to change notification settings - Fork 472
SourceMap: Replaces cwd usage in resolving paths #477
Conversation
|
Maybe I'm not able to wrap my head around it, but this doesn't (IMHO) look right: This basically translates to (for I tested your changes against my unit tests (only contains a very limited set of tests for source maps) and it didn't break. I'm probably missing something here! It's also not very clear what the "Ubuntu issue" actually is. Do you have some unit tests I could run to see the behaviour. If not, maybe you could add some to CSS-Sass!? Had not much time at hand to go through it, but still wanted to give some feedback! |
|
In case of node-sass, the current working directory (cwd) is the directory where the
With this commit:
In Ubuntu, these two test cases were failing. Supposedly, we have the following: cwd: /vagrant/temp/path/ the current implementation (without this commit) will resolve the relative paths incorrectly. |
|
@akhleung, would it be possible to merge in #471, #476 and this one soon? Please review these, since node-sass will probably be picking up a release soon. :) Thanks. @andrew, could you please provide an ETA on vNext of node-sass? This PR will hopefully fix our CI build issue for 0.11.9. Also, is there any other issue we need to fix before vNext? |
|
I had some time today to run your failing test cases with node-sass. Your patch changes the behaviour to resolve source maps relative to the Hope this makes it a bit more clearer. I personally think the current behaviour feels more natural, as all other files are referenced from cwd. Implementors should still be able to resolve relative source-map paths to the output directory if they want. IMHO the new behaviour would not feel very intuitive (i.e. on the command line). But that's just my 2 cents, so the decision is for the project owners to make (@akhleung). There might be a cleaner coding approach, If this behaviour is prefered. Best regards |
|
Sorry, I've been really busy for the past several weeks. I'll take a look at these this week. |
|
Thank you for taking time for debugging node-sass tests! 👍
I totally agree with you. For this very reason, the implementer (of node-sass for instance) would let the CLI user to pass relative path for source-map, input and output and on calling the libsass' interface, they would have to resolve abs file paths. This in on my TODO to make sure there is no change in CLI usage in node-sass. The other upstream folks would also have to make sure all three paths are absolute paths and libsass would generate the right thing for them. On the contrary, the cwd way is cleaner. But then the upstream implementer would have to take care of updating the paths in sourcemap file as well as reparse the CSS file to update the source-map comment (with regex!), which in my opinion is an expensive option. From that perspective, it boils down to: "resolving abs paths for three files input, output and source-map before calling libsass" versus "intervening with output generated by downstream (comes with costly payload)" Thoughts? |
|
IMO you would only need to check if src_map_path is not absolute, and if it is not, make it absolute in relation to dirname of output_path. Therefore libsass should never try to make it relative to cwd on its own. All other files will resolve to cwd, and the cwd could be changed by implementor before invoking libsass. Or do I miss something? The paths for sourceMappingUrl and sources in source maps are still relative to each other. |
|
This is true! 👍 This issue is fixed in node-sass repo by am11/node-sass@45219ee via sass/node-sass#411. This PR isn't required for node-sass now. |
|
👍 |
Fixes the Ubuntu issue described here: sass/node-sass#399.
/cc @mgreter, @akhleung