When I tried to use the grunt-response-images task, I encounter few errors when I tried to configure the src like that:
{
src: ['some/path/**/*']
}
This is the error I received:
Warning: Command failed: gm identify: Unable to open file (some/path/subdirectory) [No such file or directory].
gm identify: Request did not return an image.
Use --force to continue.
That's quite normal. In fact, the task try to give a directory to the image library for resizing. Logically, it is not possible to handle a directory for resizing.
I spent few hours to understand my mistake that it is mandatory to give the src like that:
{
src: ['some/path/**/*{jpg,gif,png}']
}
In my opinion, we should be able to not be forced to specify the file extensions. It will be more in the way that grunt handle the files.
To solve the issue, I added a check if the the current src path evaluated is a directory or not.
I understand that in some cases, when we mix images and other file types in a directory tree, to have the extensions in the src is clearly a better solution but in case where we have only images, a simple notation is preferable.
When I tried to use the grunt-response-images task, I encounter few errors when I tried to configure the
src
like that:This is the error I received:
That's quite normal. In fact, the task try to give a directory to the image library for resizing. Logically, it is not possible to handle a directory for resizing.
I spent few hours to understand my mistake that it is mandatory to give the
src
like that:In my opinion, we should be able to not be forced to specify the file extensions. It will be more in the way that grunt handle the files.
To solve the issue, I added a check if the the current
src
path evaluated is a directory or not.I understand that in some cases, when we mix images and other file types in a directory tree, to have the extensions in the
src
is clearly a better solution but in case where we have only images, a simple notation is preferable.