Don't pass source-map param if disabled for Scss

[tysonmatanich]

No description provided.

[tysonmatanich]

Seems like the wrong way to go about it as this would only give you editor enhancement features on what you had last saved. Any changes (until save) wouldn't have these feature and would also cause .map files to not map correctly to their corresponding files.

[am11]

This is the limitation we have in every node-depended feature in W.E.

For instance, you have a variable in a LESS/SCSS selector which depends on another variable which is defined in some import file. This kind of context can only be resolved by the compiler.

In order to preview, you need to save the file. Even on opening the source file, we also compile once to get the latest bits. With or without sourcemaps is not the catch here and it is not burdening the process.

For the other point that its not a good idea; then we would need to implement native compilers LESS, SASS, CoffeeScript, LiveScript etc. to perform quick compile in real time. Since the specs for all those technologies are changing rather rapidly (adding/dropping features every week), its way beyond the scope of Web Essentials. Also, the node-based compilation is extremely expensive for a keystroke change.

Perhaps a node-based compilation service could be the solution to such problems. See #381; we are still waiting for more feedback to finalize its architecture.

[tysonmatanich]

To add more context, I did this pull request to prep for integrating Autoprefixer. I have it mostly working, however since Autoprefixer post-processes the CSS files it runs into issues due to files being locked while the sourcemap comment is being removed. I would love to discuss more so we can get Autoprefixer added. I will add my working branch soon so you can check it out.

http://webessentials.uservoice.com/forums/140520-general/suggestions/5465425-add-autoprefixer-to-the-generated-css-output

[am11]

@tysonmatanich, this is an awesome idea!

There are couple of moving parts here. Lets start with how can we go about implementing Autoprefixer:

Starting by removing this outdated comment on CssCompilerBase.cs Line 21, after line 22; we can add another method resultSource = await AutoPrefix(resultSource) which would be an in-memory string operation: private async Task<string> AutoPrefix(string content).

This way we can avoid File I/O deadlocks (for this particular feature).

---

Other considerations:

There occur quite a number of file I/O ops on compilation. For that matter I used Microsoft Enterprise library (see #909) to consume retry policy. There were still issues reported afterwards that even after a fair number of retries it still throw "file in use" exception. So I changed it to keep trying indefinitely #981, assuming in extremely edge case scenario it would throw StackOverFlow which we will catch later (once we get hands on reproduction steps).

Surprisingly, today we get other reports saying its still throwing FileInUseException #1013 and other reporting FileNotFound exception causing VS crash and that attaching debugger slows down #1011. I made a minor change 3c98e55 putting limit on re-retry. Yet @ghorsey (via #1013) reported that issue still persists.

Reminds me of @jaredpar's quote: "The file system is the enemy of reliable programs." 😄

Some of such issues are way too subjective and needs detailed reproduction steps. We thought making "Contribution guidelines" would improve the quality of feedback, but still getting wooly details.

So, after Autoprefixer, can you please help us figuring out these File I/O crashes. It requires debugging with large codebase with lots of SASS/LESS files and tons of imports. We need to test with combinations of various settings. Since we are not using TDD, we can write test cases after devising the facts.

TIA.

[tysonmatanich]

Thanks for your feedback. I just submitted a pull request #1054