Feature - Ignore LESS and SASS files from compilation

[am11]

As per the suggestion by @tidyui; #189 (comment), we need a functionality for ignoring files from compiling on build or on save.

For that matter, we would have a .compileignore JSON file and then the menu item would say Don't compile this document to ignore it both on build an on save.

The .compileignore would work like .jshintrc; the closest in the hierarchy would be applied. Furthermore, if there is no .compileignore file found in the Solution's scope, the global one under user settings folder would be called.

In global .compileignore file, there would be a group for each project.

[SLaks]

In global .compileignore file, there would be a group for each project.
What does that mean?

[SLaks]

Also, there is no point in using JSON for that; it should work like .jshintignore and use Minimatch.Net.

[am11]

What does that mean?

Something like this:

[
  {
    "name": "project name",
    "ignore": ["/absolute/path/to/file/1.ext", "/absolute/path/to/file/2.ext"]
  },
  {
    "name": "project name",
    "ignore": ["/absolute/path/to/file/1.ext", "/absolute/path/to/file/2.ext"]
  }
]

[madskristensen]

Let's do what @SLaks suggest and adopt the format of .jshintignore and .gitignore

[gcastre]

Can't you make a property like the 'typescript compile' ?

[am11]

@madskristensen, that would be something like this?

.compileignore

{
    "1": {
        "name": "project name",
        "ignore": [
            "/absolute/path/to/file/1.ext",
            "/absolute/path/to/file/2.ext"
        ]
    },
    "2": {
        "name": "project name",
        "ignore": [
            "/absolute/path/to/file/1.ext",
            "/absolute/path/to/file/2.ext"
        ]
    }
}

BTW, except for the single line comments, .jshintrc file is in a valid JSON format:

{
    "globalstrict": false,
    "iterator": false,
    "lastsemic": false,
    "laxbreak": true,
    "laxcomma": true,
    "loopfunc": false,
    "multistr": false,
    "proto": false,
    "scripturl": false,
    "globals": {}
}

[am11]

@gcastre, I'm not sure I follow. Can you elaborate on 'typescript compile' with an example?

[gcastre]

@am11 I was talking about adding a new build action like the TypeCcript Compile option

[SLaks]

@am11: No. JSON is useful when setting properties; for a simple list of string patterns, it offers nothing but disadvantages.
And there is no point in project-specific global settings.

[SLaks]

We can't make a new Build Action because you might want the Build Action of the parent to be Content or None (or Embedded Resource in some scenarios).

It might be possible to add a separate property, but I suspect that can only be done in the project system. (creating a Project Extender might enable that?)
That also wouldn't work at all for Website Projects.

[am11]

@SLaks, yes it makes sense. But then, it would essentially be a text file with file paths separated by line-feeds? Also, I was thinking about a use-case which may involve users to save .compileignore file sitting in project directory and yet under source control, which would require relative paths in the file.

[SLaks]

It would work exactly like .jshintignore, with newline-separated file patterns.
We can copy the implementation from our pre-Node.js JSHint invoker.

[dimon82]

hey guys, thanks for working on this, it's really inconvenient to have to save master.scss as well when one of the dependencies is changed. It's actually a good idea to make developers to set up dependencies themselves in some config file rather than automatically searching for parent scss/less files as it really becomes slow when you have lots of files in your solution. I'm currently using Mindscape Web Workbench at work and it has the functionality to automatically compile master.scss but it's super slow with lots of files to search. Using Web Essentials 2013 at home and I love it (wish there was an IntelliSense support for scss though). Anyway, when do you think this feature will be done?

[SLaks]

We plan to cache the dependency graph in-memory so that we don't need to scan the filesystem on every save.
This code for that is about half-written.

However, for performance reasons, we should also switch to a set of persistent Node processes rather than spinning up Node (& reparsing the JS files) on every save; see #381.

[am11]

With 3c9c0a8 , GetDependents is no longer scanning the file system on each file save.

[jeme]

It this feature would go broader and allow to be a more global ignore...
I often have an assets folder which contains 3rd party scripts, styles and other stuff, would be useful if you could in a git ignore manner just ignore that entire folder from all WE

[vidoardes]

This issue actually makes the LESS compiller in web essentials unusable for me, I compile everything using WinLESS. Basically i have lots of files that all compile down to one CSS file in one project, and in another it compiles down to several top level files all minified. Web essentials wants to create tons of CSS files I don't want or need and doesn't give me choice over what is and isn't minified. Also note, that even if a file isn't marked for compile but it affects any that are, it needs to recompile that one to make this feature useful.

[tysonmatanich]

@vidoardes why don't you just disable all compilation (on save and on build) of LESS files through the WE settings? You can store different settings for individual solutions if needed.

[tysonmatanich]

I was thinking that Sass and LESS compilation should work more like how minification is handled. Instead of just blindly compiling the files, instead first check if a compiled file exists and if it does then and only then compile the file. To create the compiled file for the first time, just add a right click option.

This won't fix @vidoardes issue but should fix most everyone else's

[am11]

The solution for this issue on par with #638 should be reduced to a single exclusion file.

That would be little different than what we have in case of .jshintignore for example; in case of CoffeeScript, there are two things in play: linter and compiler. In order to handle the scenario where multiple services are tied to a content type, we can bring about minor alteration in line-feed-separated flat ignore list:

**/third-party/**
c:/projects/some-project/name.less
[compiler] **_aliases.sass
[linter] **variables.coffee

Notice without any prefix, it would ignore it for all services. If the service kind is mentioned in sq. brackets [], it would only ignore that service.

[tysonmatanich]

It just seems wrong to use exclusion for some things and inclusion for others. WE needs a consistent approach to use for all generated files.

[am11]

.WEignore would be used only to exclude items from getting processed in node pipeline. It will work same as .jshintignore except that it would have that optional slug: [compiler/liner] (to specify service kind).

[roadsunknown]

My vote is for following a pattern similar to .gitignore. I've recently added a line in my .gitignore for all projects to exclude any .css files inside my "/less" directory so that at least these unneeded css files are not trashing up the source. Visual Studio won't like missing project files, but what the hell.

I've tried turning off all Save on Compile for LESS, but then I'm unable to compile the single less everything wraps up in (either by saving file or saving a child).

With 89 votes in UserVoice, I'm hoping this gets some love quickly: http://webessentials.uservoice.com/forums/140520-general/suggestions/5341144-allow-less-files-to-be-ignored.

[am11]

@roadsunknown, its on final stages and it would be richer than .gitignore 😉

[am11]

Done. See the docs at #1250.

Cheers!

[roadsunknown]

This does not appear to be compiling up the chain RE: #582. Specifically in my case, I have created the .weignore and added:

**/bootstrap/*.less less
**/global/*.less    less

In another directory I have a file app.less, which imports files in the directories above. When saving file global/custom.less it saves and skips compile, but it also skips compiling up the chain forcing to manually save app.less to compile.

[am11]

@roadsunknown, why would you want to auto-compile dependent files when there is no change took place in dependent upon item?

@SLaks, @madskristensen if the file is skipped, do we need to compile the dependency chain?

I think its subjective. Some people would like to keep the current behavior; don't compile dependent files either.

[roadsunknown]

A change did take place in the dependent child, but we do not want to compile less > css for dependencies, only for the parent less.

For example:
parent.less imports child.less.

// parent.less
@import child.less

// .weignore
**/child.less less

When you save child.less, you do not need/want to compile it to css, but you do want parent.less to compile. The logic would be to skip the compile of just child.less, but not skip parent(s) (unless they are also defined in .weignore).

[am11]

Hmm but AFAICR, the actual use-case for chain compilation was to keep the outputs of imported files in sync, when the imported document is compiled and the output is altered (otherwise the files under source control would checkout for no reason).

But from your description, it seems like you are expecting chain compiler to act like Compile on Build; where are files must compile (unless their name starts with underscore _ or they are present in .weignore).

This feature explicitly checks for the condition; only compile the dependency when its already compiled at least once. Therefore, if the output of imported document is not changed, the importing / dependent document mustn't change either and there is no point in compiling it.

[madskristensen]

I think it would make really good sense to compile the parent chain unless they too are ignored

[am11]

@madskristensen it will not change the output of any importing document.

Suppose in both a.less and b.less, we have:

@import "c";

Now, if you compile c.less and output changes, in that case a.less and b.less will recompile, if the chain-compile feature is enabled in options.

But if you don't compile c.less OR c.less is ignored by .weignore, then a.less and b.less don't need recompilation because either way their output will remain the same! As if nothing has happened in first place.

[roadsunknown]

You are correct in expectations that chain compiler compile all except with underscore _ or exists in .weignore. There are numerous requests for this type of functionality in various tickets / UserVoice requests based on use of popular libraries (like Bootstrap) where renaming every file with an underscore _ is impractical. One intent is with .weignore files can be ignored for compile without requiring an underscore.

Regarding the a, b, c example, I think I follow, but the intended purpose of ignoring c.less for compilation is that it is never referenced by itself and therefore does not need its own compiled .css file. It does need to be compiled, but only as part of the import on parent(s) (if any). The extra c.css (and c.css.map) that are generated are useless and do not need to be generated.

[am11]

Yes, that makes sense. I was wrong 😄

If we make changes in c.less its output file wont be created, but a.less and b.less would expect the update. I will fix it.

PS We really need a detailed section in docs on http://github.com/madskristensen/vswebessentials.com/

[am11]

This is fixed by f433087 via #1263