I have Brunch compiling Stylus for a Backbone.js app and I can't seem to figure out how to manipulate the order. I've read the documentation, but I haven't been able to get any further. The files always get concatenated in alphabetical order, and what's worse, if I use an #import command in a given stylus file, that file will get concatenated both where I've added it as well as where it would appear alphabetically.
My config.coffee file looks like this:
stylesheets:
joinTo:
'assets/stylesheets/app.css'
order:
before: [
'vendor/styles/bootstrap.less'
]
after: [
'vendor/styles/helpers.css'
]
My folder structure looks like this:
|__details.styl
|__footer.styl
|__global.styl
|__header.styl
How can I
Omit certain files that I'm manually importing?
Specify my file order, e.g. global, details, header, footer?
I've tried to change the order in the config file by trying
order:
before: [
'app/styles/global'
'vendor/styles/bootstrap.less'
]
but this yielded no change.
I know I could just rename the files to be something like a_global and z_footer, but that's obviously hacky and it also doesn't solve my file omission problem. I'd also like to take advantage of the stylus index import ability so I can better organize my styles. However, if I were to do that now, while it works from a stylus perspective, those files are also getting concatenated to app.css in the alphabetical order of their parent directory.
Files that start with _ are ignored by compilers.
Which means, you can do
#import _first
#import _second
#import _third
in your main stylus file and _first etc will be added only once to result.
Related
I am having trouble with D's package.d feature. I have my package.d file:
module dew;
public
import dew.util;
I then have util.d:
module dew.util;
struct Size
{
int width;
int height;
}
When I try to use it in another project, it gives me this error:
I know that this should work, because projects on GitHub use it, specifically bindbc-sdl.
Your code is correct. By the error message I'm assuming your project layout with DUB probably looks something like this:
dew/
dub.sdl/dub.json
source/
package.d
util.d
However this would be incorrect. By default DUB only uses import folders instead of specifying all input source files, so the compiler attempts to discover the files from the import paths in the filesystem. The compiler dumped the import paths it searches in in your error screenshot.
The rough compiler equivalent to what it's doing right now is (see dub -v)
dmd source/app.d -Isource -I../dew/source
You need to imagine that the path whatever is written in there is invisible to the compiler, so the dew/source/ path is just some opaque string the compiler doesn't interpret. Now all that the compiler sees is a package.d and util.d in its search paths. However for imports from folders to function, they need to correspond to the filesystem layout, i.e. you need to have a folder named dew where your files are stored in.
So a module named dew.util would correspond to dew/util.d
And your package dew would correspond to dew/package.d
So for your dub project that means essentially that you need to move all your source files into
dew/
dub.sdl/dub.json
source/
dew/
package.d
util.d
Alternatively it would be possible to manually specify all files one-by-one where the compiler can look them up because of the module declarations at the top of the file, however you lose the convenience of module names being mapped to filesystem paths, which might be something other community-made D source tools and IDEs are expecting. On the command line that would be equivalent to
dmd source/app.d ../dew/source/dew/package.d ../dew/source/dew/util.d
Eg: I want to import a file called #import 's-grid-settings' in multiple different stylus files. Is this a bad idea?
It depends :)
Stylus have two ways of “importing” other stylus documents: via #import and via #require.
The difference is that #import would import the file each time, while #require would do this only once.
#require this way could be useful to share the settings and/or some common stuff like placeholders etc. between multiple stylus files in a such way those files could be either compiled each by itself or as a bundle. If the #import was used in this case, it would include all its stuff every time it was called, while #require would do this only once at the first call.
So, the answer to your question would depend on what is there inside your file.
Right now my Karma config has the following files to include:
files: [
'vendor/vendor.js',
'vendor/angular-mocks/angular-mocks.js',
'src/components/security/index.js',
'src/components/security/authentication.js',
'src/components/security/login-controller.js',
'src/components/filters/index.js',
'src/components/filters/toDate.js',
'src/components/services/index.js',
'src/components/services/alert.js',
'src/menu/index.js',
'src/menu/menu-controller.js',
'src/user/index.js',
'src/manage/index.js',
'src/manage/user/manage-user-controller.js',
'src/manage/channel/manage-channel-controller.js',
'src/stream/index.js',
'src/stream/stream-controller.js',
'src/messages/index.js',
'src/messages/messages-controller.js',
'src/app.js',
'src/**/*.spec.js'
],
The file vendor/vendor.js is automatically created by a Gulp task concatenating all vendor files using my bower config. It's all my own Javascript code that's so hard to include because order matters a great deal. The index.js files within a folder define the module (and its routes) and thus must be loaded before the individual files. And app.js always has to be last.
So my question is how I do this a bit smarter, for example with a glob that first includes all the index.js files and then all the others?
This is exactly what RequireJS is for. You can use it in your deployed code, but you can also just use it for your tests.
If you do this, your "karma.conf.js" ends up being a little shorter and less volatile. Your RequireJS config file specifies some dependency mapping. Each test spec ends up specifying what dependencies it needs, either in a "declarative" fashion in the "define" call, or sometimes manually through the "require" function (you sometimes need the latter to deal with circular reference problems).
Hm I guess asking the question gave me the idea I needed :) This works:
files: [
'vendor/vendor.js',
'vendor/angular-mocks/angular-mocks.js',
'src/*/**/index.js',
'src/*/**/*.js',
'src/app.js',
'src/**/*.spec.js'
],
Adding the *.js after index.js results in debug messages like this:
src/manage/index.js ignored. Already in the list.
Excellent!
I have a library and a console application that uses a library. The library has a folder with source and header files.
My project is in a child/inner directory but that library directory that I want to include is in a parent/upper directory.
My project directory:
H:\Gmail_04\gsasl-1.0\lib\libgsaslMain
Includes files are here:
H:\Gmail_04\gsasl-1.0\src
How can I use paths relative to the project directory, to include folders that are in a parent/upper directory?
Instead of using relative paths, you could also use the predefined macros of VS to achieve this.
$(ProjectDir) points to the directory of your .vcproj file, $(SolutionDir) is the directory of the .sln file.
You get a list of available macros when opening a project, go to
Properties → Configuration Properties → C/C++ → General
and hit the three dots:
In the upcoming dialog, hit Macros to see the macros that are predefined by the Studio (consult MSDN for their meaning):
You can use the Macros by typing $(MACRO_NAME) (note the $ and the round brackets).
If I get you right, you need ..\..\src
I have used a syntax like this before:
$(ProjectDir)..\headers
or
..\headers
As other have pointed out, the starting directory is the one your project file is in(vcproj or vcxproj), not where your main code is located.
By default, all paths you define will be relative. The question is: relative to what? There are several options:
Specifying a file or a path with nothing before it. For example: "mylib.lib". In that case, the file will be searched at the Output Directory.
If you add "..\", the path will be calculated from the actual path where the .sln file resides.
Please note that following a macro such as $(SolutionDir) there is no need to add a backward slash "\". Just use $(SolutionDir)mylibdir\mylib.lib.
In case you just can't get it to work, open the project file externally from Notepad and check it.
There are a couple of hints you need to know.
consider your app is running under c:\MyRepository\MyApp
a single dot on your path means the folder where your app runs. So if you like to reach some folder or file under MyApp folder (imagine c:\MyRepository\MyApp\Resources\someText.txt) you can do it like var bla = File.Exists(./Resources/someText.txt)
and you can go one level up with double dots (..) think about a folder under c:\MyRepository\SomeFolder\sometext.txt
for MyApp, it will be like
var bla = File.Exists(../SomeFolder/someText.txt)
and it is possible to go 2,3,4.. levels up like
../../SomeFolder (2 levels up)
../../../SomeFolder (3 levels up)
and path starting with no dots means the drive root. var bla = File.Exists(/SomeFolder/someText.txt) will look for the c:\SomeFolder\someText.txt in our scenario.
Is there a way I can include include files inside include files? (Say that five times fast!)
For example:
Inside index.html:
<!--#include virtual="/include-1.shtml"-->
Inside include1.shtml:
<!--#include virtual="/include-2.shtml"-->
So the tree looks like this: index.html <-- include_1.shtml <-- include_2.shtml
As is, this is not working on my Apache. The first include works fine, but the content for the nested include doesn't display.
As it is relevant, I am using the XBitHack on Apache 2, and I've double checked that both files are executable by the web user.
Help?
I know that this question is more than four years old, but for the benefit of people who, like me, find it thanks to StackOverflow's amazing search engine juice, here's how I made it work.
Under Apache2, you need to know this.
Relevant text:
This command inserts the text of the included file into the parsed file. SSI files may be nested, that is the included file may contain additional SSI statements (but in this case must have an .shtml suffix irrespective of the setting of XBitHack).
(Emphasis mine) For me, the solution lay in uncommenting two lines in the default httpd.conf:
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml
… and changing the filename extension of the first-level included file to .shtml:
index.html
└─┬─ include1.shtml
└─── include2.html
Boom! Nested SSI works like a champion.
Make sure that Apache is actually trying to process the *.shtml files. Try putting
<!--#echo var="DATE_LOCAL" -->
in a *.shtml file and seeing if you get the expected results. Do you get the same result in a *.html file? If you don't see the dates in both, your configuration is off.