I know there is something very obvious that I'm missing but I just can't see it. I have this simply Grunt copy file that I'm running.
copy: {
dev: {
files: [
{
expand: true,
src: [
"../index.html",
"../views/**",
"../scripts/**",
"../styles/**",
"../data/**",
"../images/**"
],
dest: "../../iPhone/www/"
}
]
}
}
Everytime I run this my files go into the ../../iPhone folder instead of the ../../iPhone/www folder. I don't understand why it's copying one level up when I'm specifically saying to copy into the www folder. Again I know I'm missing something so trivial and small, but I just can't see it. Thanks in advance.
EDIT: Just found something very interesting. If I add an arbitrary folder after www (i.e. ../../iPhone/www/assets) then it will correctly copy to the www folder since it's one level up from assets AND the assets folder is NOT created.
The grunt copy command will, by default, replicate the path of the src into dest.
In this case, using .. is the source (no pun intended) of your problem.
You can work around this by using the cwd property
Your task config would look something like:
copy: {
dev: {
files: [{
cwd: '../',
expand: true,
src: ["index.html",
"views/**",
"scripts/**",
"styles/**",
"data/**",
"images/**"],
dest: "../../iPhone/www/"
}]
}
}
Related
I want all js file from dev-> js folder and dev->bootstrap->js should minify to build-> js folder and build->bootstrap->js
I am trying to use following code but this is not working
uglify: {
build: {
files: [{
expand: true,
src: '**/*.js',
dest: ['build/js', 'build/lib/bootstrap/js'],
cwd: ['dev/js', 'dev/lib/bootstrap/js']
}]
}
}
Error coming as -
$ grunt
Running "uglify:build" (uglify) task
Warning: Path must be a string. Received [ 'dev/js', 'dev/lib/bootstrap/js' ] Us e --force to continue.
Aborted due to warnings.
<pre>
// incoming
dev
|js
|lib
|bootstrap
|js
// output
build
|js
|lib
|bootstrap
|js
</pre>
If you look at the grunt documentation for building the files object dynamically, you will find the following definitions:
dest Destination path prefix.
cwd All src matches are relative to (but don't include) this path.
This is telling us that dest must be a string, not an array, and it must be the folder under which all compiled files will go. In your example, this is the build/ folder.
Secondly, it tells us that cwd is a string indicating the folder under which all source files are to be found. Additionally, it tells us that the src file paths will not include this folder prefix when they are mapped to dest file paths. In your example, all source files are relative to the dev/ folder.
Your grunt configuration for your uglify:build task should be updated as follows:
files: [{
expand: true,
cwd: 'dev/',
src: '**/*.js',
dest: 'build/'
}]
I'm using grunt to copy some files, I have this entry that copies fonts:
copy: {
copyFonts: {
files: [
{
expand: true,
src: ['src/theme/type/**'],
dest: 'output/css/type/',
filter: 'isFile',
flatten: true
}
]
}
}
This was working fine, however recently I had to have fonts in separate folders but this command "flattens" the structure. Now simple setting flatten to false doesn't work. As it then creates all folders from the root and copies them into the destination folder.
e.g.
src/theme/type/font1 will be copied into
output/css/type/src/theme/type/font1
and I want
output/css/type/font1
How to change it that it only takes the folders (and content) from within the type folder and copies across to destination?
In an inherited polymer 1.0 project the setup involves a gruntfile which calls, among other things, bower to install the necessary resources. However, in the later steps, some files cannot be found and the grunt task fails. I am new to both bower and grunt and feeling a little lost.
The file in question that cannot be found is myproject\components\polymer\polymer-mini.html, though there are more in similar positions which I found out by copying the file there by hand.
My first step was to isolate the bower install task and watch it while it was working. This is its configuration in the gruntfile.js:
bower: {
install: {
options: {
targetDir: './components',
layout: 'byType',
install: true,
verbose: false,
cleanTargetDir: true,
cleanBowerDir: true,
bowerOptions: {}
}
}
}
By pausing the execution after single steps in verbose mode I found the following to happen during installation:
the old myproject/components folder is deleted if it exists
files are created as normal in a myproject/bower_components folder
files are then copied to the targetDir myproject/components
however, not all files seem to arrive there
myproject/bower_components is deleted after copying
Comparing the contents of myproject/bower_components and myproject/components reveals that many files present in the original folder are missing in the target one. For example, the mentioned myproject/components/polymer only contains a polymer.html - however, there are seven files in myproject/bower_components/polymer, including the missing polymer-mini.html.
Apparently, something filters what is copied to the targetDir and what isn't.
Can I influence this in any way or is this setup even correct as it is now? I have seen grunt-bower-task and Polymer but cannot make much of it - except that the accepted solution apparently copies everything by hand after the installation of bower_components. Surely, there must be a better way?
I ended up copying the files independently of the bower task by calling a copy task configured as such:
copy: {
main: {
files: [
{ expand: true, cwd: 'bower_components/', src: ['**'], dest: 'components/', filter: 'isFile' }, // bower components
]
}
}
Of course, in this case the bower task has to be reconfigured not to delete the bower directory from which to copy.
bower: {
install: {
options: {
targetDir: './components',
layout: 'byType',
install: true,
verbose: false,
cleanTargetDir: true,
cleanBowerDir: false,
bowerOptions: {}
}
}
}
This isn't really what I hoped for but in the meantime it gets the job done.
I have a project generated with JHipster and would like to deploy it inside a context in Tomcat (not at root context).
There seems to be grunt task to change image and font to use a full path in the css. (cssmin)
I have found this link to remove the cssmin but did not succeed in preventing this problem.
I'm searching a way to continue using the same task (cssmin) and be able to deploy a JHipster app in any way possible (as Tomcat root context or in a context /jhipster).
The current master branch contains a fix for this. If you can't wait for the next release you need to modify your Gruntfile.js.
First: Make cssmin use relative paths by removing the option root: 'src/main/webapp'
Second: You need a seperate copy task to copy the required fonts into the correct directory:
copy: {
fonts: {
files: [{
expand: true,
dot: true,
flatten: true,
cwd: 'src/main/webapp',
dest: '<%%= yeoman.dist %>/assets/fonts',
src: [
'bower_components/bootstrap/fonts/*.*'
]
}]
}
Third: Add the new copy task to the build task by adding 'copy:fonts' to the build tasks.
I'm trying to copy some fonts into a directory named 'fonts' To do this, I am trying to use the grunt-contrib-copy task. My task is setup like this:
fonts: {
cwd: 'src/vendor/library/release/fonts',
expand: false,
src: [ '*' ],
dest: 'build/temp/fonts/'
},
When this gets executed via grunt, the verbose output shows:
Running "copy:fonts" (copy) task
Verifying property copy.fonts exists in config...OK
Files: myfont.eot, myfont.svg, myfont.ttf, myfont.woff -> build/temp/fonts/
Options: processContent=false, processContentExclude=[]
Options: processContent=false, processContentExclude=[]
Copying myfont.eot -> build/temp/fonts/myfont.eot
Reading myfont.eot...ERROR
Warning: Unable to read "myfont.eot" file (Error code: ENOENT). Use --force to continue.
What am I doing wrong? Why aren't my font files getting copied?
Thank you!
You have to set expand to true, and that works for me.
Actually, I got this idea from you.
Reference: grunt-contrib-copy reference
I had this very issue. What I found was I was using 'grunt-copy' and not 'grunt-contrib-copy'. I uninstalled grunt-copy with npm uninstall grunt-copy and ran npm --save-dev grunt-contrib-copy and things worked as expected.