This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi, I just played with twitter/bootstrap which is based on .less, and came across my first little problem. All .less files are split out into modular files, then you have 1 main file where you put all your @imports, so everything compiles into the final output file. https://github.com/twitter/bootstrap/tree/master/lib All the smaller module files use functionality from each other, and they do not have @import declarations in them, because otherwise the final output file would compile pretty weirdly. The problem is that WW does not recognize things that where declared in the other files, because there is no @import in them, and so you get a lot of error messages saying this or that variable is not declared, but if you start adding @import to these files so that WW stops giving errors, the final output will be completely false because recursive @imports are now happening. My suggestion/request is to create a variable that mimics @import exactly, but works at runtime only, and gets discarded at compile time.
Something like this would probably be more compatible, triple slash. Intellisense would still pick up the @imports, but compile-time would ignore them.
What do you think ? ..or maybe i'm missing something like that, that exists already - Robert |
|
|
|
|
I'd second this request, I'm a bit disappointed I didn't realise this till after buying the pro version specifically work with bootstrap :( Edit: Sorry I stand corrected - the issue was with the latest version of bootstrap (2.02) which has some funky stuff in the #grid section which is causing lots of compilers problems. Once I rolled back WW handled it perfectly. Cheers guys -Will |
|
|
|
|
I also can't compile Twitter's Bootstrap and that was one of the main reasons for getting the Pro version. It's really hampering my workflow. |
|
|
|
|
Hi folks, This feature is now available -- do an update through VS Extension Manager to get it. Please report any issues! Because the proposed @using syntax would result in files that could not be compiled with the Less compiler, we adopted a 'specially formatted comment' approach. The syntax you need is: Note that it is your responsibility to make sure that when you @import a file that contains a ww-expect, you also import all the files it depends on. For example, if File A ww-expects File B, and File C @imports File A, it is up to you to make sure File C also @imports File B. We do not provide a wiggly for this, but the Less compiler will undoubtedly report an error when you compile! In a future release we hope to move 'co-import expectations' into the Web Workbench Settings page so you can manage them using a GUI and do not need to edit the Twitter Bootstrap files, but we hope this will improve your experience for now! |
|
|
|
|
If anyone decides to implement this on the latest Twitter Bootstrap, then I'll be more than grateful for the download :) |
|
|
|
|
wtg, thanks ! |
|
|
|
|
Awesome stuff, cheers for the amazingly quick action! |
|
|
|
|
Am I correct that the //* ww-expect doesn't work when the .less-file is in a different directory? //* ww-expect "../bootstrap/variables.less"; //* ww-expect "../bootstrap/mixins.less"; Tried this in the latest nightly (3 jun), in VS 2012 RC. |
|
|
|
|
No that should work. If you have a look at the Bootstrap mixins file though you will see that there it doesnt currently parse correctly in WW, so this is likely the issue you are running up against. We are working on adding in extra parsing support to handle the issues. If you just use the variables include that should work happily.
|
|
|
|
|
We are looking at buying Pro at work (I already have it). I was wondering, does this method accept absolute paths? I think that would be really helpful when you are several layers up and want to easily get back to a different top-level folder and not worry about moving your file around: Is safer than: Because the second one breaks as soon as you move. I think it would be safe to assume that the base directory is the project directory, but perhaps make it configurable? I can't think of a reason it wouldn't be relative to the |
|
|
|
|
The ww-expect extension is passing through the path to a file system based resolver so any valid directory path can be used here (e.g. C:\Temp\foo.less) or App_Data\foo.less. Project relative paths (e.g. ~/foo.less) are not valid for this reason. If you need things to be project relative then you will need to use ../../ style paths and you will need to keep them updated if you happen to move your files. Ill make a note of this as we may look to update this in the future to support both styles.
|
|
|
|
|
Thanks, this would be very helpful for multi-tiered projects and for deep configuration. We have a convention that I don't expect will change overnight, but I think it's better to be safe (absolute paths) than sorry (relative paths). |
|
|
|
|
I am using VS2012 RTM and this syntax doesn't seem to work, even though it does for my coworker who's using VS 2010. I've tried the following lines: Any ideas? I am putting these at the top of a LESS file. The first line messes up highlighting for the rest of the file |
|
|
|
|
@genmills: I had a similar problem when I was running Web Essentials 2012 and Web Workbench at the same time. I disabled Web Essentials and the posted syntax worked just fine. (Web Essentials seems to go hand-in-hand with VS2012 so I figured it was worth a shot that this might be your issue too) It seems like the first slash was throwing off the syntax highlighting since it thought the rest of the line was a multi-line comment and the first slash was therefore part of some uncompleted rule. The following helped with the syntax highlighting, but the code was still throwing a lot of squigglies: |
|
|
|
