I use Gulp to run one simple task in a non-JavaScript project. I'm trying to upgrade from 3.9.1 to 4.0 to get rid of the flood of "deprecated" and "security" warnings. Together with articles like A quick guide for switching to gulp 4 I've upgraded locally, dropped gulp-util and ended up with this package.json:
{
"name": "redacted",
"main": "gulpfile.js",
"private": true,
"devDependencies": {
"ansi-colors": "^3.0.5",
"fancy-log": "^1.3.2",
"gulp": "^4.0.0",
"gulp-zip": "^4.2.0",
"temp": "^0.8.3"
}
}
But I'm not a Node.js expert and I'm clearly missing something. My old style tasks:
var gulp = require('gulp');
var log = require('fancy-log');
gulp.task('hi', function() {
log('Hello, World!');
});
… trigger:
PS D:\Redacted> gulp hi
[10:25:58] Using gulpfile D:\Redacted\gulpfile.js
[10:25:58] Starting 'hi'...
[10:25:58] Hello, World!
[10:25:58] The following tasks did not complete: hi
[10:25:58] Did you forget to signal async completion?
If I inject gulp.series() and get rid of anonymous functions as the article recommends:
function hi() {
log('Hello, World!');
}
gulp.task('hi', gulp.series(hi));
… then either the task runs twice or its output gets displayed twice (not sure) but the warning persists:
PS D:\Redacted> gulp hi
[10:28:47] Using gulpfile D:\Redacted\gulpfile.js
[10:28:47] Starting 'hi'...
[10:28:47] Starting 'hi'...
[10:28:47] Hello, World!
[10:28:47] The following tasks did not complete: hi, hi
[10:28:47] Did you forget to signal async completion?
What bit am I missing? Is there a better upgrade guide?
The old-fashioned syntax still works. I was apparently just missing a final call to the done callback that didn't seem to be required on Gulp/3:
gulp.task('hi', function(done){
log('Hello, World!');
done();
});
gulp.series() looks like overkill for running a single task.
Related
In an AngularJS 1.7 project, I've managed to migrate my gulp configuration files from 3.9 to 4.0.2, but the http server won't start with a "gulp serve"
I've :
Converted all the dependencies to a "series" task. I used series everywhere, as I think it's safer (and slower) than using parallel execution.
gulp.task('default', ['clean'], function () {
gulp.start('build');
});
to
gulp.task('default', gulp.series(['clean']), function () {
gulp.start('build');
});
Reorder the require('./gulp/somefile.js') manually so that tasks are defined before being called. (before it was loaded by a loop)
within each files put the function definition before the task call them
When I do a "gulp serve", I can see the build output showing the same 'normal' errors I had before migration (non angularjs lib added manually), and some new warning from bootstrap-sass about deprecated division.
After the build part, I would expect a local server to start on port 3000, Chrome being launched with the web UI i'm developping being displayed and my REST call being proxied to a local apache/php server, but well, it doesn't start, no error/warning, nothing.
[00:41:33] Finished 'styles' after 1.6 s
[00:41:33] Finished 'inject' after 2.31 s
[00:41:33] Finished 'watch' after 2.31 s
[00:41:33] Finished 'serve' after 2.31 s
The configuration files are here : https://github.com/dev-mansonthomas/RedCrossQuest/tree/ComposerLibUpdate/client
gulp.js
and then all files in the gulp sub directory.
gulp.start was never really intended for end users and is unneccesary with gulp.series. I wouldn't doubt support for it was removed from v4. Just use:
gulp.task('default', gulp.series('clean', 'build'));
I have a gulp task that contains this task:
gulp.task("js", function() {
console.log('Gulp task JS run')
gulp.src('scripts/*.js')
.pipe(sourcemaps.init())
.pipe(include())
.on('error', console.log)
.pipe(sourcemaps.write('./maps'))
.pipe(gulp.dest("public/javascripts"));
});
I try to run the task from node like this:
var gulp = require('gulp');
require('../../gulpfile');
if (gulp.tasks.js) {
console.log('gulpfile contains task!');
gulp.start('js');
}
And I see "gulpfile contains task" and "Gulp task JS run" in the console, but the it it doesn't seem to actually run, the files are not updated. When running it manually from bash with "gulp js" or from the watch task, it works fine.
Is there any reason this would happen or any way I can troubleshoot it further?
I am trying to make my processes (webpack, nodemon-restart) work with a single gulp command. This works well enough. However, webpack builds only once if its task is tied to gulp's default task (together with nodemon), or embedded withing nodemon's gulp task.
Then I decided to tie both webpack build task and nodemon restart task to gulp's watch command and this works just the way I wanted, except that if you make changes and save them more than twice, the app nodemon crashed and prints this error in the console
"/home/nnanyielugo/Workspace/activity-calendar/node_modules/nodemon/lib/monitor/match.js:132
var rules = monitor.sort(function (a, b) {
^
TypeError: Cannot read property 'sort' of undefined"
As a solution, i tried to tie the webpack build task to the nodemon restart using the .on() method, and instead got an infinite loop of restarting an rebuilding (nodemon restarts first, webpack builds, nodemon restarts again, webpack rebuilds, and on and on).
Does anyone have a solution please?`
Here is a sample of my code `
var gulp = require('gulp'),
nodemon = require('gulp-nodemon'),
webpack = require('webpack-stream');
gulp.task('default', ['watch']);
gulp.task('webpack', function() {
return gulp.src('src/entry.js')
.pipe(webpack(require('./webpack.config.js')))
.pipe(gulp.dest('./public'));
});
gulp.task('nodemon', function () {
return nodemon({
script: 'app.js'
, ext: 'js html'
, env: { 'NODE_ENV': 'development' }
})
})
gulp.task('watch', function(){
gulp.watch(['./api/**/*.js', './server/**/*.js', './*.js'], ['webpack', 'nodemon']);
})`
I guess, your nodemon and gulp's watch task collides with each other. Either you should get ride of using nodemon and to rely upon gulp to start your application.
Or else, you can get rid of your gulp's watch task and add the relevant script in your nodemon's restart method like this,
nodemon({
// script goes here.
}).on('restart', your_reload_logic)
Hope this helps!
I've spent a fair amount of time trying to debug this, and figured I would ask. I even created a GitHub repository but won't rely on it, so here goes. I'm trying to take advantage of CommonJS syntax within the Karma test runner using PhantomJS. For my module I created the simplest thing I could think of:
exports.returnYes = function() {
return "Yes";
};
The Jasmine test is:
var returnYes = require("../js/returnYes").returnYes;
describe("returnYes", function() {
it("should return Yes", function() {
expect(returnYes()).toBe("Yes");
});
});
And, if I do a jasmine init I can run it from the command line thanks to jasmine-npm by simply typing jasmine with output:
$ jasmine
Started
.
1 spec, 0 failures
Finished in 0.003 seconds
Now to try and get it to work inside karma:
I create my karma.conf.js with frameworks: jasmine,commonjs. And, I add commonjs as preprocessor.
I try to do a karma run and I find that it can't find global which is part of getJasmineRequireObj in jasmine.js where it declares jasmineGlobal = global;
The command line output is a little hard to read, but here it is:
$ karma run
[2015-06-27 17:41:35.266] [DEBUG] config - Loading config /Users/zen/Projects/karma-commonjs-test/karma.conf.js
##teamcity[enteredTheMatrix]
##teamcity[testSuiteStarted nodeId='1' parentNodeId='0' name='karma.conf.js' nodeType='config' locationHint='config:///Users/zen/Projects/karma-commonjs-test/karma.conf.js']
##teamcity[testSuiteStarted nodeId='2' parentNodeId='1' name='PhantomJS 1.9.8 (Mac OS X 0.0.0)' nodeType='browser']
##teamcity[testStarted nodeId='3' parentNodeId='2' name='Error' nodeType='browserError']
##teamcity[testFailed nodeId='3' error='yes' message='ReferenceError: Can|'t find variable: global|nat http://localhost:9876/base/node_modules/jasmine-core/lib/jasmine-core/jasmine.js?68f13ab3f93af5a219b9fe8409f8763b31998bba:27']
##teamcity[testSuiteFinished nodeId='2']
##teamcity[testSuiteFinished nodeId='1']
For good measure here are the devDependencies in my packages.json:
"devDependencies": {
"jasmine-core": "^2.3.4",
"karma": "^0.12.37",
"karma-commonjs": "0.0.13",
"karma-jasmine": "^0.3.5",
"karma-phantomjs-launcher": "^0.2.0",
"phantomjs": "^1.9.17"
}
I'm not sure why I can't find global. Any help would be greatly appreciated!!! :)
It seems like my whole problem came down to the line in karma.conf.js (not shown in my original question:
preprocessors: {
'**/*.js': ['commonjs']
},
For some reason, jasmine.js is not happy being pre-processed by commonjs, and "**/*.js" says to go through all subdirectories (which is probably overkill), including node_modules which has jasmine-core/jasmine.js
So I can either make my pre-processor more specific (best practice):
preprocessors: {
'spec/*.js': ['commonjs'],
'js/*.js': ['commonjs']
},
but as a test to see if any other files would give me a problem, I tried:
preprocessors: {
'**/!(jasmine).js': ['commonjs'],
},
And, everything worked as well. Bottom line. Do not process jasmine.js through commonjs preprocessor!
I've been using netbeans for a long time. I mostly work with php, html, css and javascript primarily in relation to wordpress theme and plugin development. I run Netbeans 8.0.2 (and for testing gulp the latest nightly build) under windows 7.
I'm just getting started with grunt and / or gulp (leaning towards the latter so far), at the moment to take advantage of autoprefixer - but I see a million other potential benefits of these systems.
There is one showstopper though. I got addicted to the "Upload files on save" feature years ago, and I'm not about to kick that habbit - the instant upload is a very central part of my workflow on almost all projects...
So far it has just silently handled anything I threw at it, and automatically uploaded any changed files no matter if I used netbeans, photoshop, windows explorer or any other external program to modify or move files around... but it doesn't play nice with the recently introduced gulp and grunt support.
If I run a gulp (or grunt) task and files are updated, netbeans doesn't detect the changes until the changed files are opened (or tabbed to if already open)... and so the updated files aren't uploaded.
If the task runs as a watch it doesn't seem to matter if I run it from CLI or from netbeans. If it's a "normal" task (ie. not a watch - I'm not quite comfortable with the lingo yet) and I run it manually by right-clicking the Gruntfile.js -> Grunt Tasks -> whatever then the changes are detected... but this isn't very convenient (compared to my usual "deployment procedure" of pushing CTRL+S). So far this built-in way of running tasks works for grunt - but not (yet?) gulp.
Only options I see is to:
use an FTP plugin for grunt or gulp - very undesirable for a number of reasons
run gulp on the server side - which would mean a major disruption of the normal workflow when full control of the server is not possible, which is often the case on external projects - it would also mean a lot of extra initial work to set up each new project serverside even when it is possible
Has anyone managed to get this working in a similar scenario?
-Any other suggestions / pointers are welcome too, if I'm simply going about it completely wrong.
More or less minimal (based on my so far limited knowledge) files to reproduce:
package.json:
{
"name": "grunt_gulp_test",
"version": "0.0.1",
"description": "",
"main": "gulpfile.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "Mikkel",
"license": "ISC",
"devDependencies": {
"grunt": "^0.4.5",
"grunt-contrib-sass": "^0.9.2",
"grunt-contrib-watch": "^0.6.1",
"gulp": "^3.8.11",
"gulp-autoprefixer": "^2.3.0",
"gulp-load-plugins": "^0.10.0",
"gulp-sass": "^2.0.1",
"gulp-sourcemaps": "^1.5.2",
"gulp-util": "^3.0.4"
}
}
Gruntfile.js:
module.exports = function(grunt) {
grunt.initConfig({
sass: { // Task
dist: { // Target
options: { // Target options
style: 'expanded'
},
files: { // Dictionary of files
'test_grunt.css': 'test.scss'
}
}
},
watch: {
scripts: {
files: ['test.scss'],
tasks: ['sass'],
options: {
spawn: false
}
}
}
});
grunt.loadNpmTasks('grunt-contrib-sass');
grunt.loadNpmTasks('grunt-contrib-watch');
grunt.registerTask('default', ['sass']);
grunt.registerTask('watch_it', ['sass', 'watch']);
};
gulpfile.js:
'use strict';
var gulp = require('gulp');
var gutil = require( 'gulp-util' );
var $ = require('gulp-load-plugins')();
gulp.task('styles', function () {
return gulp.src([
'test.scss'
])
.pipe($.sourcemaps.init())
.pipe($.sass({
precision: 10,
onError: console.error.bind(console, 'Sass error:')
}))
.pipe($.autoprefixer({browsers: ['> 5%']}))
.pipe($.sourcemaps.write())
.pipe(gulp.dest('.'));
});
gulp.task('default', ['styles']);
gulp.task('watch', ['styles'], function () {
gulp.watch(['test.scss'], ['styles']);
});
test.css:
div {
div {
display: flex;
background: #445552;
}
}
This was confirmed to be a bug for users running on windows.
The bug has been resolved, and until it is included in a stable release, anyone else who is affected by the problem can simply use a nightly build >= 201508060002