Changing an imported less file does not recompile the parent about less-sbt

[softprops]

I think the extra setting is more doable. I don't actually have direct access to transitive info. That's all wrapped up inside the in rhino javascript context. It's not exposed directly. It should be realitivly easy on the otherhand to provide a task which does a different check than this which compiles all less sources. Thanks for bringing it up.

[kastigar]

Hi!

What do you think about to have two settings for filter? First is for "files to compile" and the second is "files to check for modifications"?

[softprops]

That sounds like an option. Is the first filter a file or files that should always be compiled?

[kastigar]

No.
Now plugin has filter setting that means "What files to compile". And compile task checks was that files changed. If file was changed then recompile it.
My approach is to add new setting checkFilter (for example) that means "What files to check for changes". So task will check checkFilter's files for changes and then will recompile filter's files if needed.

This way is good for my use-case: i have one main.less file that has a bunch of imports so i will have:
filter = "main.less"
checkFilter = "*.less"

It is worse if you have couple or more "files to compile" - it will cause compilation of all "files to compile" when one imported less-file was changed.

But anyway it is better then files that will be always recompiled, especially if you have compile task dependent on less task

[sroebuck]

This seems like a viable option to me. It would also cope, I think, with my recent attempt with trying to compile Twitter Bootstrap which currently tends to compile the sources in alphabetical order, thus encountering errors due to file dependencies.

[softprops]

I'm going to try taking a stab the complementing filters. @sroebuck try taking a look at my scripted test for twttr's bootstrap project. The alphabetical ordering is something sbt does in file collecting. What twitter actually does when they build a distribution is only compile less/bootstrap.less I tried emulating that by overriding the filter key

(LessKeys.filter in (Compile, LessKeys.less)) := "bootstrap.less"

And it works great.

At least for building a distribution css file. It doesn't help with this bug, continuous compilation through source change detection. Say one of bootstrap's dependencies change. My plugin wouldn't thing compile bootstrap.less, but rather the dependency which creates is own problem when that dependency may not have importing the variables it may need.

I think I have a better grasp on the problem now.

[softprops]

Didn't quite get this one done tonight. What do you guys think about this setting contract? Is it confusing

 lazy val filter = SettingKey[FileFilter]("filter", "Filter for selecting less sources to compile. When importFilter is None, any stale files attributed to this filter will be compiled.")
 lazy val importFilter = SettingKey[Option[FileFilter]]("import-filter", "Filter for selecting less sources that represent targets of less file imports. When stale, these will trigger the compilation of all files attributed to the filter setting.")

If I default importFile to None the plugin should be backwards compatible. If you set importFilter to Some(your import filter) a change for compilation selection changes such that any stale file within the importFilter will trigger any file matching the filter filter to be compiled instead.

Does that make sense? Would you find that confusing.

[kastigar]

@softprops, this solution is good for me!!!

[sroebuck]

As an additional suggestion, how about having a default that everything in a lib subdirectory (or sub-sub, etc.) is in the importFilter and the lib subdirectory is excluded from filter (e.g. is in excludeFilter)?

In a very small number of cases this might impact on existing users. However, for those who are not so familiar with sbt configuration, it would provide an 'out of the box' configuration by convention. e.g. if you have libraries to include put them in lib or a subdirectory of it; if you want less-sbt to compile it directly put it anywhere else.

[kastigar]

@sroebuck, good idea to have predefined structure for less building. It can solve all inconveniences of less-sbt.
So you're proposing such default values:

filter = "*.less"
excludeFilter = "lib/*"
importFilter = "lib/*"

If so, i am agree with you.

[sroebuck]

Yes, exactly!

[softprops]

I hate to make too many assumptions about how users want to structure there code but I guess lib is common name for a directory of locally vendored dependencies in projects. How about if I provide a custom set of settings you can mix in that others who don't need and leave out, something like

 seq(nestedLessSettings:_*)

which appends the overrides you mentioned to the default set of settings in lsSettings. How does that sound?

[kastigar]

Will be seq(nestedLessSettings:_*) used instead of seq(lessSettings:_*) ?

Btw, additional request. Can be importFilter automatically appended to excludeFilter(runtime)? So you don't need to care about saving it in excludeFilter.

[kastigar]

btw, folder for imports can be named as imports :)

[softprops]

sounds good. I can't really focus on this at work. Ill check it out tonight and post then.

[sroebuck]

I like the idea of the folder being called imports — that makes sense.

However, I do think that sbt can be extremely confusing and unnecessarily so. Asking users to understand nested dependencies of configurations might make complete logical sense, but in practical terms I think it's just too confusing.

To be completely honest, whilst I may possibly understand sbt more than most, I still tend to treat configuration of sbt plugins like black magic. I look on the respective site, look for an example of how to configure something and think:

(some magical expression on the left including symbols like <= :+ := etc.) [a setting on the right of a particular pattern]

Okay, I'll copy the left verbatim and then produce something on the right that follows that pattern but reflects the setting I want to set.

Talking to a number of users I know I'm not alone.

So, whatever choice of configuration you go for, the most important thing is that there is a worked example of that particular configuration in the README because for most people there is no clear mapping between the line:

exclude-filter(for less) # filter for files ignored by the plugin

and:

(LessKeys.excludeFilter in (Compile, LessKeys.less)) := "lib"

Sorry, that's one of my regular sbt is far harder to use than it needs to be rants which is certainly not aimed at you. Or anyone for that matter :)

[softprops]

I like the idea of the folder being called imports — that makes sense.

what's wrong with lib again?

To be completely honest, whilst I may possibly understand sbt more than
most, I still tend to treat configuration of sbt plugins like black magic.
I look on the respective site, look for an example of how to configure
something and think:

(some magical expression on the left including symbols like <= :+ :=
etc.) [a setting on the right of a particular pattern]

If you understand sbt that well setting binding really shouldn't be that
confusing. In fact, the setting system is probably the bulk of sbt now.

So, whatever choice of configuration you go for, the most important thing

is that there is a worked example of that particular configuration in the
README because for most people there is no clear mapping between the line:

I'm working on a project to help rectify that,
https://github.com/softprops/sox, should should server as a standard
documentation format for sbt settings.

Mark does welcome input on his list for how thing could be made easier in
sbt. Mark usually has more insight into problems that most people including
me, a build tool has to solve across the board for all different kinds of
build requirements.

[softprops]

I think I'm going to stick with lib at least for now. It's already used as std name for dependencies in java, ruby, scala, node, and more type projects. I wouldn't want to introduce a special case. It looks like that would actually make bootstrap itself easier to see what's what and where to put shared code.

Also note, I do not want to fashion this plugin after the needs of a bootstrap style less codebase. You can get plenty of mileage from a single less file which is what bootstrap.less amounts to be after being compiled.

[softprops]

File change detection. requires a include+exclude filter. I just realized that if we want to exclude lib dependencies, we'd also need a new setting for lib exclusions otherwise the lib filter + default exclude file would cancel each other out. I feel like some complexity is creeping in, maybe necessary, but I really want to avoid any complexity.

I want to get a release out with the other fix so I think I'll do that now and this and the relative import issue can be a close follow up release when I figure out something that requires less thinking. (no pun intended). My work thus far on this issue is on the imports-filter. So if you want to play follow the progress. Thats the branch to watch.

[kastigar]

Sorry, @softprops. We make so much headache to you.

I want to try another way. I want to make less-rhino.js returns an import tree for compiled file. So we will not need an additional settings and imports can be checked automatically. So probably you can forget about this setting. I'll let you know about results.

[softprops]

I think @kastigar's awesome pull req fixes this

[softprops]

@kastigar If you can confirm that, I'll push an 0.1.6 release.

[kastigar]

@softprops, yes that pull request fixes this issue

[sroebuck]

Very cool. Well done.

[softprops]

Cool, I'll push a release tonight. Thanks for all the input and help guys.

[kastigar]

Thank you for the project!

[softprops]

published http://implicit.ly/less-sbt-016