WE compiles sass files on open, instead of safe

[joneff]

I did mention this in another issue: #871

---

With the 2.0.4 update an interesting bug was introduced: WE would compile sass files (including the entire dependent tree if any) on open. There is also this message in the status bar compiling X dependent files for NAME.scss

The problem persists with 2.0.5 update.

My folder structure

-- mixins
  |-- _all.scss (includes _part.scss)
  |-- _part.scss (has a generic mixin)
-- test.scss (includes mixins/_all.scss)

But in reality you only need one include file and one that includes it.

[am11]

As mentioned earlier; this is by design.

If you don't want to turn off dependent file compilation, go to Tools > Options > Web Essentials > SASS > Auto-compile dependent files on save.

[joneff]

As I mentioned earlier: I am not saving files, but merely opening them.

[am11]

Yes; this is exactly what we have implemented.

[joneff]

Why would you do so? It makes no sense! Not to mention it's not consistent:

• Why aren't T4 templates recompiled on open?
• Why aren't typescript / coffee etc files recompiled on open?
• why aren't ordinary sass files compiled?

About your last comment: Open and Save are two different actions and should not be the same setting.

Also, I do believe that most people would not want their files to be recompiled. Just for the sake of argument, imagine cherry picking among 1k+ files which files to indeed check in and not.

[am11]

Why would you do so? It makes no sense!

We generate CSS source-map to enable editor features; specificity, Go To Definition etc.

•Why aren't T4 templates recompiled on open?
•Why aren't typescript / coffee etc files recompiled on open?

This is confined to CSS preprocessors (LESS and SASS).

About your last comment: Open and Save are two different actions and should not be the same setting.

That I removed as soon as I posted. It was about giving clear message in settings, so there is no confusion in future to other people. I removed it because since most of the people look for error messages and not worry about Output logs, and this is something for the internal editor use anyway it may not be needed.

Also, I do believe that most people would not want their files to be recompiled. Just for the sake of argument, imagine cherry picking among 1k+ files which files to indeed check in and not.

Currently, we are triggering compile action on opening document. All the work is done in background meaning the UI thread would be free (no freezing). If in future we get the reports of high CPU usage, we can consider decoupling the not-on-demand (on document open) compilation process from getting chained-compiled.

I tested with bootstrap projects (mostly ASP MVC), which has tons of LESS files. Also tested by opening my ROR projects with VS (as website) and compiled SASS files.

You can test with various cases too. If it gives you trouble (high CPU usage or jarring experience), then changing the behavior would make perfect sense. Its good for most cases but not the ultimate solution. Until #381 is implemented, we are relying on background asynchronous tasks to keep the experience smooth.

[joneff]

It's not the CPU that worries me. If it did, I would use sass --watch in a specific dir or a specific file. It's the I didn't want to do this (recompile) part that worries me and the associated actions. Like mass checkout...

We work in a source controlled environment (TFS) and, as I said before about 1200 sass files. Now add 5 front end developers and a total of 40 people interacting with the code at any given moment. Sass compile time is quite short -- with the checking out it takes about a minute or so.

But its really time consuming to keep track of which files you intended to change and which not.

Or imagine that you didn't want to work / fix / do something a code part that when recompiled would break. Now, if I save the global include file, it's my fault.

Or imagine that you did a faulty click... Or you have enabled previewing files and happen to click on the include... Or you are just browsing the code...

I am not arguing that this feature is useless. I am arguing that it's powerful enough to be behind a setting.

---

On a side note: what would happen if I am not allowed to checkout files, but I open such file and the recompilation is triggered?

[am11]

Lets consider the actual implementation. Here is what happens:

• When a SCSS (or LESS) document is opened in editor with preview enabled, it simply reads the (previously) compiled code and display the result in preview window.
• In case we don't have the compiled form, it triggers InitiateCompilationAsync.

To get the desired behavior:

We can check if the request is cached, send a signal (var) to CompilerChainer EvenHandler lambda function. For this matter, we might need to create OurOwnEventHandler (inherits generic EventHandler) here or misuse the first parameter (sender; s in lambda.. which is never used anyway).

This probably won't have any side-effects (not one I can think of by its looks).

[am11]

This is fixed by 7feac7c.

Try out http://1drv.ms/1ePY9mB and let me know so I can send a PR.

[am11]

@SLaks, should we remove Mef.GetChainedCompileExtensions() method and ChainCompilation class?

[joneff]

@am11 This fixes the issue.

It also fixes an occasional crash of when I open sass files.

[am11]

Cool!

I am sending the PR now. This issue can be closed.