Support for Source Maps

[cuchac]

I'm going to implement sourceMaps to sassphp. Is there any previous work related to this? I will also work on Sacy parts, so if you are connected with that project, is there any previous work on this?

Reply from @pilif:

I wrote 99% of sacy, so yeah. I'm familiar with that and I also was looking into source maps and let me tell you: There are challenges ahead:

• Due to the way how sacy currently works, it really wants to feed the to-be-transformed content to the processor as a big string. When using libsass, this would be done using Sass::compile() and when using the ruby sassc, this is done using stdin. At least in the case of sassc, you can't have source maps when using stdin.
• This also means that at the time when you run the sass compilation, the information what source file the data came from is not available any more, especially when you use sacy with the merge_tags feature (which you will want to use if you want to have globally available mixins). As such, you won't get any meaningful mapping to the original file.

If you have ideas on how to work around these issues, I'd be excited to have a look at an eventual Pull Request, but all approaches I tried so far were less than optimal in their outcome.

[cuchac]

What if I focus on just the "simple" use-case that I need?
I'm not using merge_tags and I'm using sassphp.
Would it be okay to change sacy to use file compilation API in this case (instead of string compilation)?

What if I use one global file that imports any other file. Will sacy also merge the content of all imported files to one single string? If not, maps could work even without modifying Sacy (using string-compiling function in sassphp).

[chrinor2002]

Isn't source maps something supported by libsass(3.1.x) now? We should just be able to implement the APIs to provide source map output. Or am I totally out to lunch on that...

[pilif]

yeah - to do this inside l sassphp isn't the problem - provided we update the bundled libsass, of course (which is totally fine by me).

The initial comment was referring to pilif/sacy which is a completely different story and which will be really tricky to implement source maps for.

[chrinor2002]

Ahh that makes more sense. I actually have plans to update to libsass 3.2.0 once the official release comes out. Maybe someone (with WAY more C knowledge than me) could put in source maps magic after we get that merged?

[absalomedia]

I maintain a fork of the Sensational code that does generate source maps & comments. Initial build was with Libsass 3.1 but it's now compatible with Libsass 3.2.4. Unsure how well a pull request would do with the amount of changes I've done.

[pilif]

in general, I'm very interested in merging our work - we don't need a ton of forks around and the only reason there is no sourcemap support in my repo is because I didn't yet have time :p

However: I would want to be careful to not break backwards compatibility for our users too much, so I have to ask: How API compatible is your branch?

[absalomedia]

It wouldn't be a clean merge unfortunately.

master...absalomedia:0.4.5

Most of the merge issues are due to documentation & version changes as I split out a different build name & version number to help differentiate. Most of the changes inside sass.c & similar C level code would be API compatible. I've also got a few more unit tests to add - some still very unstable.

I'm also running a slightly dirty edition of the linked LibSass build as I'm also midway to 3.2.5 testing.

[pilif]

It wouldn't be a clean merge unfortunately.

don't worry about that. I'm Mr. Merge in my day job :-)

If it's ok with you, I'll wait until you are done with 3.2.5 testing and then, I would cherry-pick what's needed from your branch, fixing conflicts as they happen. I would then also give you push access to this repo here as, clearly, you have more time than I have to work on this.

[absalomedia]

The only reason I've been having to get source maps / comments into sassphp is due to demands in my day job as there are project dependencies requiring SASS source map generation on the fly.

The aim has been to get 100% SASS coverage for the design teams I work with. As 3.2.x is close to that coverage I'm actually working on it less.

HHVM compatibility for sassphp in my own build is just a far future concept I'm considering at the moment as the projects I'm with are considering long term deployment with HHVM.

I've just passed stable testing with Holiday Patch (3.2.5) so just merge from version 0.4.5:

master...absalomedia:0.4.5

[mooror]

Hey yall. I'm new to this particular conversation but I just wanted to see how the merging is going. You see the company I work for is wanting to move to a much more integrated (php) system for compiling our code and this project looks very promising. Ideally though we would like to have sass source map support, which is why I'm here...so yeah... Also while I'm here, can someone please write a full fledged tutorial for installing this (and libsass if possible) on a windows test server (specifically ammps).

Thanks in advance,
Mooror

[absalomedia]

@mooror the current build will not compile under Windows in any way shape or form. It's Linux / Mac only. I have been considering the possibility of a Wintel build at moment

[mooror]

Sorry for the late reply. I think that a windows build of this would be awesome as many people us windows for development. However I do happen to run a dual boot on my pc so there shouldn't be any problems for me specifically. Mind you it is fedora and that might cause complications. Hopefully not but if so I will make sure to post another comment(or open another thread somewhere) .

Thanks,
Mooror

[absalomedia]

I'm currently running both Travis & Appveyor CI build testing on my particular fork. I can confirm no issues with Linux or Mac OS build specs. Appveyor, I'm still getting a handle on, as my expertise generally isn't Windows based PHP DLL extension building.