I am trying to run the following grunt command grunt test:e2e but this does not seem to work as I get the warning as pointed in the title. I don't want to post the entire gruntfile.js so I have supplied the gist link. I would really appreciate if someone can point me in the right direction.
Gruntfile.js
The error should be your clue here; there are no task targets named "livereload-start". If you want to point to a specific task config given this structure:
connect: {
target1: {
// opts
},
target2: {
// opts
}
}
You would run connect:target1 instead of connect-target1. If you remove livereload-start out of your task configuration (line 379), what happens?
Related
I keep on getting ES6 jshint warnings, for example:
''import' is only available in ES6 (use 'esversion: 6'). (W119)'
source: 'jshint'
code: 'W119'
I followed suggestions such as
Adding a .jshintrc file in the root with
{
"esversion": 6
}
Adding the following to the user and\or workspace settings:
"jshint.options":{
"esversion":6
}
But I still get the warning. Are there other things that I can do?
Thanks
Add a file .jshintrc into your project root, the warnings will disappear.
{
"esversion": 6
}
jsHint's ES6 warning can be solved easily by the following JSON code without creating any new file:
Paste the code inside the JSON editor of the "user settings".
"jshint.options": { "esversion": 6 },
jsconfig.json file which defines the JavaScript target to be ES6
I create a jsconfig.json file under my project directory and add codes in it:
{
"compilerOptions": {
"target": "ES6"
},
"exclude": [
"node_modules",
"**/node_modules/*"
]
}
According to the JSHint documentation: https://jshint.com/docs/ "In addition to using configuration files you can configure JSHint from within your files using special comments. These comments start with a label such as jshint or globals..."
So, a /* jshint esversion: 6 */ comment will work on the top of each file targeting ES6.
This have the advantage of you can switch these directives on and off per file or per function: "These comments are function scoped meaning that if you put them inside a function they will affect only this function's code."
I'd like to add a grunt task that accepts a version number. This version number will then be set in the package.json file. I have found grunt-bump, which bumps the version number, but I would like to set the version number to a known value, that will come from the build server.
Grunt task:
grunt.registerTask('setversion', function() {
// Something to go here to update the version number.
});
package.json:
{
"name": "scoreboard",
"version": "0.2",
...
}
Anyone got any idea's?
You could use something like:
grunt.registerTask('setversion', function(arg1) {
console.log("Attempting to update version to "+arg1);
var parsedJson= grunt.file.readJSON("package.json");//read in the current
parsedJson["version"] = arg1; //set the top level version field to arg1
grunt.file.write("package.json", JSON.stringify(parsedJson, null, 2));
});
add in some error checking etc.. make sure package.json is writable and execute with grunt setversion:newVersion e.g.: grunt setversion:0.3
Thanks for the answer, but it turned out to be a lot more straightforward. I am using TeamCity, so I ran an NPM task with the following command, where %system.build.number% follows the pattern n.n.n, e.g.: 0.1.6.
--no-git-tag-version version %system.build.number%
I keep getting this error with UNCSS: 'Warning: Destination (dist/css/main.css) not written because src files were empty. Use --force to contine. Aborted due to warnings.
I believe it's running the task fine and is set up properly. I can use grunt for other things.
In gruntfile.js, I've included: grunt.loadNpmTasks('grunt-uncss');
and
uncss: {
dist: {
files: {
'dist/css/main2.css': ['../index.html']
}
}
}
I'm not sure what's wrong, but I think it's the pathing, but that's just how it is. I'm also using SCSS, so maybe it needs a raw css as SRC? I've tried reinstalling PhantomJS and the raw UNCSS without Grunt, but I'm going no where! Any ideas?
I found the solution.
It wasn't necessarily the pathing, but how the pathing was presented.
I was using
files: {
'dist/css/main2.css': ['../index.html']
}
I switched to
files: [
{ src: 'index.html', dest: 'dist/css/main.css' }
]
Here, the src & dest are declared.
This blog helped me deanhume.com.
The github/NPM documentation didn't work for me, but this guy's did. I hope this helps someone!
I'm writing am openembedded/bitbake recipe for openembedded-classic. My recipe RDEPENDS on keyutils, and everything seems to work, except one thing:
I want to append a single line to the /etc/request-key.conf file installed by the keyutils package. So I added the following to my recipe:
pkg_postinst_${PN} () {
echo 'create ... more stuff ..' >> ${sysconfdir}/request-key.conf
}
However, the intended added line is missing in my resulting image.
My recipe inherits update-rc.d if that makes any difference.
My main question is: How do i debug this? Currently I am constructing an entire rootfs image, and then poke-around in that to see, if the changes show up. Surely there is a better way?
UPDATE:
Changed recipe to:
pkg_postinst_${PN} () {
echo 'create ... more stuff ...' >> ${D}${sysconfdir}/request-key.conf
}
But still no luck.
As far as I know, postinst runs at rootfs creation, and only at first boot if rootfs fails.
So there is a easy way to execute something only first boot. Just check for $D, like this:
pkg_postinst_stuff() {
#!/bin/sh -e
if [ x"$D" = "x" ]; then
# do something at first boot here
else
exit 1
fi
}
postinst scripts are ran at roots time, so ${sysconfdir} is /etc on your host. Use $D${sysconfdir} to write to the file inside the rootfs being generated.
OE-Classic is pretty ancient so you really should update to oe-core.
That said, Do postinst's run at first boot? I'm not sure. Also look in the recipes work directory in the temp directory and read the log and run files to see if there are any clues there.
One more thing. If foo RDEPENDS on bar that just means "when foo is installed, bar is also installed". I'm not sure it makes assertions about what is installed during the install phase, when your postinst is running.
If using $D doesn't fix the problem try editing your postinst to copy the existing file you're trying to edit somewhere else, so you can verify that it exists in the first place. Its possible that you're appending to a file that doesn't exist yet, and the the package that installs the file replaces it.
I am using command line options in my grunt script: http://kurst.co.uk/transfer/Gruntfile.js
However the command grunt --vers:0.0.1 always returns 'undefined' when I try to get the option:
var version = grunt.option('vers') || '';
Can you help me get this working ?
I tried different (CLI) commands:
grunt vers:asd
grunt -vers:asd
grunt vers=asd
as well as using :
grunt.option('-vers');
grunt.option('--vers');
But no luck so far. Hopefully I am missing something simple.
This is my package.js file:
{
"name": "",
"version": "0.1.0",
"description": "Kurst EventDispatcher / Docs Demo ",
"devDependencies": {
"grunt": "~0.4.1",
"grunt-contrib-yuidoc": "*",
"grunt-typescript": "~0.1.3",
"uglify-js": "~2.3.5",
"grunt-lib-contrib": "~0.6.0",
"grunt-contrib-uglify":"*"
}
}
The proper syntax for specifying a command line argument in Grunt is:
grunt --option1=myValue
Then, in the grunt file you can access the value and print it like this:
console.log( grunt.option( "option1" ) );
Also, another reason you are probably having issues with --vers is because its already a grunt option that returns the version:
★ grunt --vers
grunt-cli v0.1.7
grunt v0.4.1
So it would probably be a good idea to switch to a different option name.
It is worth mentioning that as the amount of command line arguments you want to use grows, you will run into collisions with some arguments that grunt uses internally.
I got around this problem with nopt-grunt
From the Plugin author:
Grunt is awesome. Grunt's support for using additional command line options is not awesome. The current documentation is misleading in that they give examples of using boolean flags and options with values, but they don't tell you that it only works that way with a single option. Try and use more than one option and things fall apart quickly.
It's definitely worth checking out