I have split my less/css into several files grouped by certain categories, so the single files stay easy to maintain. Though I only want to have one css file which gets imported into the layout.
For this I have - how I call it - a master less file which imports all the others like config, forms, layout and so on.
Now the problem is, that for example WinLess or all the other copilers i tried, only monitor the save of my master file, and only then compiles it. However this is stupid, because this file nearly never gets any changes. So what I would like to have is something, that detects changes on the imported less files and then only compiles the master file.
Does anyone know any tools, which are capable of that?
Or how do you manage your less files to bypass this problem?
Further Info: I have mapped the server directory locally via SSH and edit the files in there, i.e. the files are only pseudo local. They are on the server but accessible with a local path over a drive letter. The compiler should be able to work with that setup.
Thanks for the answers!
In all honesty, your best bet is to actually use Less's own compiler which will of course be the most up to date option. It will be done through command line but it's the best way to know that everything is correct, working and up-to-date.
All the information can be found in the Less Documentation Here
More information about compiling with imports can be found HERE
The latest version of WinLESS does report that it has automatic re-compiling when an #import file is changed so it could be that your version of WinLESS is out of date. (See HERE - 3rd bullet point under Features)
Alternatively, see if you can get it to work on purely local files. If this works, it may be an issue with the compiler not being able to do asynchronous checks over SSH.
I use Notepad++ with the NppExec-plugin on-save script. If you make a convention decision to always name your primary file "master.less" you can use this script:
NPP_CONSOLE 0
NPP_SAVE
if $(EXT_PART) != .less goto end
"C:\Node.JS\node_modules\.bin\lessc.cmd" -x "$(CURRENT_DIRECTORY)\master.less" > "$(CURRENT_DIRECTORY)\master.min.css"
:end
You can do something similar with any editor that supports batch scripting (like Stewartside suggests)
Related
I'm running JetBrains ReSharper 8.2 on a project that uses SASS for styling.
I compile my seperate scss files into one file "common.css". This file is not included in the project, but gets compiled on build on the server (grunt + compass takes care of this).
I don't want to include this file, but only my SCSS files in the project. This however causes ReSharper to report a lot of errors ("Unknown CSS class"...) in my views because the file isn't included.
Is there a workaround for this (without disabling css errors in settings)?
I've tried the "ReSharper.ExternalCode" extension (https://resharper-plugins.jetbrains.com/packages/ReSharper.ExternalCode), but without any luck.
Sadly, there isn't a workaround for this. ReSharper doesn't know about SCSS files, and doesn't know anything about files that aren't included in the project, so it can only assume the CSS classes are undefined.
The external code plugin should work and allow ReSharper to process the resulting css file. However, I'm not sure how flexible it is - I think it needs everything to be configured before the solution is opened. That is, it only tells ReSharper about the generated file when the solution is being opened. Configuring things while a solution is open probably won't be reflected immediately (but I haven't tried it). Similarly, it doesn't notify ReSharper of changes to the file, and I don't think that ReSharper sets up any monitoring. So if the file isn't available when the solution opens, or changes while it's open, ReSharper won't have correct information. I'd try and configure it, close the solution and reopen.
I'm considering using LESS for CSS development with server (or development) side processing, but I can't decide if I should keep the generated CSS files in version control. There are plenty of solutions with hooks, but this adds software dependencies to the server. A hook could just be added locally so staging and production areas on the web would get the same files. So, the question is:
Should generated CSS files be included in version control or not? Please keep in mind that some frameworks require a CSS file to exist for a particular reason (i.e. WordPress themes require a style.css file in order to be recognized).
When I say 'considering using LESS', I mean it becomes a requirement. New developers would not have the option use vanilla CSS after the choice is in favor of LESS.
Checking in derived artifacts is almost always sub-optimal.
I vote no to checking in the .css. It's only a matter of time until one of your peers or successors checks in an edit to the .css and not the .less. Then when you change the .less the prior change is lost.
You've pretty much answered your own question. It depends on how you deploy your website.
If the server is just going to pull directly from the Git repository:
1) It needs to have software installed to generate CSS from LESS.
2) or you need to include the CSS files in the repository.
If you're not pulling straight from the repository on your web server, you could have a build script that pulls from git, generates CSS, and then transfers the content to the web server(s), possibly excluding unnecessary files from the transfer.
In my opinion, Git should be used to keep all of the source for a project, and none of the "derived artifacts" (as mentioned by #thekbb). Developers need to have all tools installed to generate those derived artifacts during development and test. For deployment to test and production servers, an automated build server should take the source and create just the files needed for distribution.
In the case of software development, you'd have a Makefile with .C and .H files (for example) in your Git repository. Developers and the build server have a compiler installed that will create an executable or compiled library. When the files are packaged for distribution, the source code is not a part of the archive.
For web development, you have source files like original graphics, HTML templates and LESS files. Developers and the build server can run scripts to generate the site assets (CSS from LESS files, static HTML pages from templates, flattened images in multiple sizes/formats, etc.) When the build server deploys new builds, it copies just the files needed by the server, excluding the source graphics, templates and LESS files.
If there are people that need to review the site content, they should do it on a staging server. If that's not possible, the automated build server can create a ZIP file on an internal server that they can download for review.
Should generated CSS files be included in version control or not?
In theory they should not, but for practicality, I do usually checks in the generated css file. The reason is that it simplifies deployment since I do deployment using git; I would not need to have a less compiler installed on the server and usually not even on the machine I'm deploying from (as opposed to the machine where I'm developing on). Doing this could be useful if you have separate developer and deployer, but can sometimes also be useful even if you're deploying yourself.
Now, there are drawbacks on doing this:
You can't use git add --patch (or you really need to be very careful when doing so)
You should not modify the .css directly; instead I usually use a secondary .css file to do minor modifications without modifying the primary .less or .css file. You can also compile .less file straight into a minified css, to make it less tempting to modify the generated css.
Developers have to set up their machine to use automatic recompile tool (like SimpLess or Less.app), so the .css file is updated as soon as they save to the .less file. Without automation, you'll run into risk of the css not matching the checked-in less file.
I would not do the same when compiling from .C and .H files though, because the generated binary for those are platform specific, and also .less/.css file is usually a very small part of a larger web project so the space overhead of the additional file is small.
Good question. If you can absolutely guarantee that the CSS file gets updated when the LESS gets updated then perhaps yes - as per #Scott Simpson's comment. I suspect that this would be difficult to guarantee and what happens when the new developer get's a copy of CSS the day when they are out of sync? Also, of course, and I hadn't originally thought of this, what happens if the new developer then makes updates to the CSS file rather than the LESS?? If the CSS has to be built and isn't part of archive I can see less problems.
I would say yes -- because what happens if you want to add a developer to your workflow and they don't want or need to build .Less? It would be helpful for them to have access to only the generated file.
On a new project I have started, XCode has decided that it will compile every file in the project every time I run it, rather than just compiling files that change (and files dependent on those). As there are getting to be more and more files in the project, this becomes a bigger and bigger burden in both time and battery life.
It is possible that I have changed a setting somewhere that affected this; or, maybe not. What are some project settings that I should be looking at?
If Xcode recompiles most or all of your source files whenever you do a build, that usually means that those files are all directly or indirectly dependent on some header file that has changed. Here are some things to look for:
Do your source files tend to #import some top-level header file that itself recursively imports a bunch of lower-level header files? If any file in that tree of dependent headers is modified, it will force recompilation of any .m file that imports the top-level header file. You may be able to reduce these dependencies by importing headers for lower level submodules, or better yet, for just the specific headers you need for each file. (Note: Some libraries that aren't designed to be used this way can make this approach challenging or impossible in some cases.)
Some third party development tools and static libraries run scripts that generate or modify code as part of their build process. If your source files are dependent on a header file that's generated by a script, they'll be recompiled every time the script regenerates that header file. Even if the code generated by the script doesn't change, dependent source files will be recompiled if the last-modified date of the header file changes. It may take some clever hacking to eliminate redundant compilation if this is your issue.
Don't forget to check your precompiled header (.pch) file to see what's being imported there. The contents of that file are effectively injected at the top of every .m file in your project at compile time.
Try to minimize dependencies by moving as many #import statements as possible out of your .h files and into your .m files. You can generally get away with just importing the headers for your class's superclass and any protocols your class implements in its .h file. You can use forward declarations instead of #import statements for any other classes, data types, or protocols you use in your class's #interface.
I realize this question is over a month old, but I had a similar problem in moving an old project to Xcode 4. After much hair-rending, I discovered that Xcode 4 (4.2 in my case) has a bug where, if there are any non-ASCII characters in the full path either of a source file, or in the full path of any headers the source file includes, it will be recompiled every time you build. This includes the prefix header, in which case a full compile will be triggered every time. In my case, the previous programmer had appended 'ƒ' to several folder names, and once I removed those, it worked perfectly.
Anyway, I stumbled upon this question during my (unsuccessful) attempts to Google an answer and thought I'd share my solution.
I noticed that Eclipse (Flex Builder) generates hundreds of metadata files. Should I check them into my source control? They seem necessary, because if I delete them Flex Builder just opens up an empty workbench...
Some of these files plainly do not belong in source control (like .history files and some cache files). If I delete them my project opens up again without a hitch. But the list is long and there seem to be no clear separation between folders that contain files that belong in source control and those that do not.
I can't just shove them all into svn, even if I were to ignore the inefficiency, because Eclipse generates new ones constantly, with different names, which in turn also seem to be crucial for the project to load.
Can someone please enlighten me?
Don't check in the hundreds of metadata files. If you want to be able to check out the project in a way that it can just be imported, then check in:
.actionScriptProperties
.project
.flexProperties
And "html-template" and "libs". As Christian says, any resources you depend on. I usually keep those as separate Flex Library projects though.
I generally put all of my source code under src, and I check in src and all of its descendents. If my project relies on any external dependencies (e.g., the Cairngorm SWC, as3corelib, etc.), Flash/graphical assets, stylesheets, or resource files, I check those in, too. But I don't check in any generated (bin-*), intermediate or IDE-specific stuff, because having that stuff in source control doesn't seem to provide much practical benefit, and in my experience has only caused me headaches; in general, I check in the most minimal set of whatever I'd need -- given a clean FlexBuilder installation (or none at all -- for example, if I were compiling instead with mxmlc or compc) and an empty project -- to build the project successfully.
Most of the eclipse project files, like .project, .properties, everything in .settings, can go into your source control. As long as the files don't have user-dependent settings like file paths or local urls, you should be fine.
One method we use is creating local property files that don't get used in SCM, but are included in the ones that do. I.E an ant build file including a local.properties file which has local metadata.
What if the .actionScriptProperties, .project, or .flexProperties have user-dependent stuff in them? Typically this will be url or path information. What's the best practice way of externalizing this? I tried creating path variables, but this only works obviously for paths. Not for things like hostname, etc.
if you're familiar with Liferay you'll know that when you make an itsy-bitsy change to a css file you shall rebuild the theme and redeploy it.
As for redeploying I made a symlink (mind you I'm on Windows: for the curious creating a symlink on Vista is just a matter of issuing mklink /d dir1 dir2).
But what about rebuilding the stuff with maven? I'd rather skip that step. Basically what it does is combyining and packing all CSS in one everything_packed.css. Is there a sort of config variable to tell liferay just to include the raw files and skip redeployment alltogether?
Thanks
Guys I found the solution myself.
You should have a file called portal-ext.properties file in
$TOMCAT_DIR/webapps/ROOT/WEB-INFO/classes
Or more specifically for my win setup in
C:\liferay\webapps\ROOT\WEB-INF\classes
The file would hold the value
theme.css.fast.load=false
This will prevent liferay to be looking for the everything_packed.css and so you're free to modify your stuff without rebuilding and CTRL-R to refresh the page and see the changes.
Just for completeness, as this question is somewhat old and the problem already solved: There's a lot more along these lines, e.g. javascript, layouts etc. that can be used uncached. This is documented in either the Liferay Wiki (as Developler Mode) or the Development Guide, available from the documentation site (though currently it's not there for the last version - if it's still not there when you're reading it, look for it (PDF) in the older versions.
It's advisable to use these settings only in development, not in production, as putting all css and javascript in as few files as possible results in a huge performance impact.
to include all those settings, just can also just add the following line into your portal-ext.properties file:
include-and-override=portal-developer.properties
this will include all the developer specific settings, and when you want to remove them, you can just comment out this line.
you can edit the css files of your theme from Webapps{your theme}\css
And can see the changes directly.
You can edit almost every file which doesn't require compilation.like .jsp files but not .java files