-
Notifications
You must be signed in to change notification settings - Fork 465
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
Fixes regressions introduced in previous merges #455
Conversation
Thank you @mgreter. I was just about to install everything on my new system to fix this. 👍 |
There still needs to be few fixes to be made. The idea really is:
Both of the above assertions aren't complied by libsass at the moment. For that matter: First, we need to store Secondly, in "/*# sourceMappingURL=" + resolve_relative_path(source_map_file, source_path, cwd) + " */"; I guess after that the API will be quite flexible and finally browsers will be able to locate correct sources with source maps generated by libsass. Thoughts? |
Note that this does *not* collapse x/../y sections into y. This is by design. If /foo on your system is a symlink to /bar/baz, then /foo/../quux is actually /bar/quux, not /quux as a naive ../-removal would give you.
Adds canonical file resolving where appropriate. It might should be noted that output_path does not mean that libsass will write the result to that location. It is merely used to create file paths relative to the output file (which defaults to input_path with a 'css' extension).
Accounts for parent references (`..`) in `stripped_base`.
@am11: Libsass already resolves sources relative to the source map file. I have added some additonal commits which should do what you have asked for (sourceMappingURL relative to output_path). @akhleung: With these changes paths are internally always represented with forward slashes. The |
Add a source entry for stdin. This mimics exactly the behavior of the Google Closure Compiler on stdin data.
@mgreter, thanks! All these changes are extremely useful. 👍 Regarding the source-map initializer issue, please see the |
Points to working directory (ending with a slash) if no input file path has been given (i.e. on 'compile_string').
Thanks @mgreter! 😃 👍 |
Sorry, I just haven't had time to look at it yet. Will try to get it merged soon. |
@mgreter, yes; all our path-related concerns regarding Hopefully we get the mapping issue fixed as well. I don't have right insights about the sass-compiler's internals and how it reports sources. If you guys can take a look or point me to the locations in code so I can give it a try, it will truly make a big impact and help many affected out there.. Thanks! |
Looked over the code and it looks good ... I'll test/merge it in the morning when I have access to my work machine. |
Fixes regressions introduced in previous merges
Merge o'clock has begun. On Fri, Aug 8, 2014 at 9:09 PM, Aaron Leung notifications@github.com
|
Indeed 😃 I wish if someday node-sass will get blessed with such a thing: "Merge o' clock"... node-sass has been insanely slow lately in adapting changes from libsass, accepting PRs, releases and all those usual things which happen to a repository.. |
Unfortunately, it looks like node-sass's maintainer is no longer able to devote time to the project: |
Can anyone else take the throne and keep the wheel spinning? |
Fixes a few issues introduced in recently merged pull requests.
#441:
resolve_relative_path
would always return lowercase paths on windows, which will not work if one would deploy the files to a linux server (or any other case sensitive filesystem). Implemented a better and IMO correct way to handle this. Also introduced a preprocessor directiveFS_CASE_SENSITIVE
so that the behaviour could be overruled on compile time.#440:
sourceMappingURL
is always added even ifsource_map_file
was not set to anything at all.