This is a pretty dumb question, but I haven't really been able to find a satisfactory answer: How do I use gulp globbing to select all files in all subdirectories below a certain directory?
I've tried:
'./src/less'
'./src/less/'
'./src/less/*'
None of them seem to work.
The pattern for all files under all directories is usually ./src/less/**/*.* or ./src/less/**/*, either should work.
Generally speaking, it's better to match specific files extensions — even if they should all be the same — to prevent grabbing system files or other junk. In that case, you can do ./src/less/**/*.less for just .less files, or something like .src/less/**/*.{less,css} for both .less and .css files.
The Grunt website has a pretty good reference for the majority of minimatch globs. (Both Grunt and gulp use minimatch, since it's the glob library for pretty much everything Node related.)
It would be nice for gulp or minimatch to have their own complete docs, but that's open source for you.
'./src/less/**' seems to work. Still, if someone has a more definitive list of all globbing commands, I would be happy to accept your answer and add it to the gulp docs. Right now you have to go to the docs for one of gulp's submodules, which then gives you a list of manpages. It would be good to have a direct reference, especially for designers using gulp.
Related
I am trying to import several SCSS files(page1.scss, page2.scss and ..) in my app.scss but I haven't found any solution(plugin and etc).
I saw these answers but they are for Ruby on Rails not libsass. I am using:
Gulp,
Gulp-sass,
Libsass and
Laravel Elixir
Any solution?
Long answer short:
As you can find in this issue in the official libsass project github, globs are not part of SASS specification, so there are no plans to support them in libsass.
why?
The main concern about implementing this feature is related with the order importing the files. In first place, AFAIK there isn't a standard way on how reading stream files behave in different OSs (linux, mac os x, windows) or filesystems (reiserfs, ext3, ntfs, fat32, etc.), what leads to a unpredictable ordering while importing the files.
Anyway, even if there will be some sort of cross-platform standard support to read files from every filesystem and you are sure you are always gonna get the files in the same order. Which order should it be?.
if you still need/want it:
Still there are some hack-y ways you can achieve this behaviour but I will strongly recommend to avoid them and follow the official recommendations.
There is a ruby gem: sass-globbing. But it doesn't works with gulp/libsass because of the different way they handle files streams. Inspired on this ruby-gem there is gulp-css-globbing. It looks like this project is a bit outdated, but you can use it on your own risk.
And in this blog post: Sass Directory Imports With Gulp, you can find another solution that involve automatically creating a file per folder that imports all files inside. A bit convoluted for my taste but it will work if you really need this.
I use browserify for dependency injection of my angular modules. However, this is only for javascript and some of my angular modules in my node_modules/ also include css. What's the best way to concatenate these files into a single css file. I think this should be easy but can't find any project that does exactly what I do in a proper manner. I'm sure there must be more people using browserify that came across the same problem.
Most of my HTML, JavaScript and CSS files are written with a lot of spaces and comments that just add to the bulk. To keep editing simple, I prefer to have them this way, however, it's not so good on my website. Is there an easy way to minify these files before uploading to my server, or perhaps use cPanel to minify them?
It sounds like you're looking for grunt.js ( http://gruntjs.com/ ), or something similar, like gulp.js.
They're just task-runners, build-automaters, etc. I know grunt already has modules available that do minification/concatenation/other space saving things, and you can probably make your own module to FTP them to your server.
You could also achieve the functionality you're looking for by just writing a simple BASH script.
How do I use webpack with famo.us
I found a seed https://github.com/Vertice/famous-webpack-seed and have seen it in use with grunt before. I was wondering if anyone could help me implement it with Gulp. I don't seem to be able to figure out how to get gulp-webpack to find and use the famous modules. Either through the pre compiled require version or the npm uncompressed version.
No doubt the webpack is useful to those who have lots of gulp specific stuff, and I think it's great to see the number ways of being able to get going with Famo.us is increasing, but I think the official generator-famous starter is a lot more fully featured, better documented, and has easier commands IMHO.
I'm working on a project with two other developers that's built on FireBreath. So far, I've been able to get things working perfectly on my machine, but we need to coordinate our development via Mercurial. So I pushed my files to the repository and thought all was well.
Unfortunately, that doesn't work.
The various .vcproj files that make up the solution all contain hard-coded references to my local file system. This works fine for me, because I'm not moving the project around. But when you try to build the solution on another machine with a different file structure (different drive letter, different folder location, etc.) everything breaks.
I used FireBreath's standard project generation script (Python) and then the Visual Studio CMake script (prep2008.cmd) to generate the solution files. What can I do to tweak things so that other developers can use the same code base?
If your developers are not using the same build/make/project files, this could quickly become a maintenance nightmare. So you should definitively all use the same .vcproj files. (An exception to this would be if the project files were generated from some other files. In that case treat those other files in the way described above.)
there's two ways to deal with the problem of differing setups on different machines. One is to make all paths relative to the project's path. The other is to use environment variables to refer to files/tools/libraries/whatever. IME it's best to use relative paths for everything that can be checked out with the project, and use environment variables for the rest. Add a script that checks for the existence of all necessary environment variable, pointing out the meaning of any missing ones, and run this as a build prerequisite, so whoever tries to get a new build machine up and running gets hints at what to do.
To make sure that everyone caught the updated comments from sbi's answer, let me give you the "definitive" answer from the FireBreath devs.
Your build directory is disposable; you should never share .vcproj files. Instead, you should regenerate your build/ directory any time you change the project and on each new computer, just like any project that uses CMake.
For more information, see http://colonelpanic.net/2010/11/firebreath-tips-working-with-source-control/
For reference, I am the primary author of FireBreath and I wrote the article.
I'm not familiar with FireBreath, but you need to make the references relative, and then recreate that relative structure on every machine. That is, if your project sits in "c:\myprojects\thisproject" and has an additional include directory "c:\mydir\mylib\include", then the latter path needs to be replaced with "....\mydir\mylib\include".
EDIT: I rewrote my anyswer to make it clearer. When I got you correctly, your problem is that FireBreath generates those .vcproj files with absolute paths in it, and you want to use this .vcproj files on a different developer machine.
I see 3 options:
Live with it. That means, make sure, every team member has the same file structure / view to the file system, tools installed in the same place.
Ask the authors of FireBreath to change their .vcproj generator to allow relative paths, use of environment variables etc.
If 1 or 2 does not work, write a program or script for changing the absolute path to relatives in those .vcproj files. Run this script whenever you have to regenerate your FireBreath project.
What you should not do due to the FireBreath FAQ: don't change the .vcproj manually, those changes will be lost next time the project is regenerated.
EDIT: seems that "option 4." turned out to be the best solution: generating those .vcproj files for each developer individually. Hope my suggestions were helpful, either.