Question

此问题......

...让我记得另一个，但似乎有所不同。（在code之后向下滚动，看看我的意思）

我在其他项目中对gulp-watch没有真正的问题，特别是因为我修复了类似的问题。（你可以在这篇文章的末尾找到）

但在这个项目（更大的网络应用程序）中，我认为nodejs / gulp-watch达到了极限。

我从 gulp （通过gulp-watch）获得的JS文件在被多次触发时似乎已损坏。

Javascript文件......

gulp

...没有损坏。
...没有损坏，在观察事件的第一次认可的变化上。
...经常被破坏。

我比较了好的和坏的（损坏的）生成的JS文件，并认识到，一个文件丢失了他的内容的一半。

意思是：

它停在JS文件的中间并继续下一个JS-File。（只占js文件的一半）

之前和之后的所有其他JS文件都会连接而不会丢失。

有谁知道这个问题，知道如何修复？

我已经尝试过了......

...添加gulp-wait延迟500毫秒，但这没有效果。
...检查此位置的代码是否错误，但似乎有效。
...重启机器。

环境： Debian Jessie上的NodeJS 4.4.7。

终端输出： 这8个启动脚本任务不会立即触发。保存文件并将其上传到Gulp正在观看的服务器和目录时，这是不同的检测到的更改。（箭头，工作和失败的文本不是输出的一部分）

user@host: /path/to/vhost/public$ gulp watch
[20:09:02] Using gulpfile /path/to/vhost/public/gulpfile.js
[20:09:02] Starting 'watch'...
[20:09:02] Finished 'watch' after 25 ms
[20:09:32] Starting 'scripts'...
[20:09:32] Finished 'scripts' after 84 ms <- worked
[20:09:49] Starting 'scripts'...
[20:09:49] Finished 'scripts' after 51 ms <- failed
[20:09:51] Starting 'scripts'...
[20:09:51] Finished 'scripts' after 38 ms <- failed
[20:09:53] Starting 'scripts'...
[20:09:54] Finished 'scripts' after 68 ms <- worked
[20:10:01] Starting 'scripts'...
[20:10:02] Finished 'scripts' after 63 ms <- worked
[20:10:18] Starting 'scripts'...
[20:10:19] Finished 'scripts' after 59 ms <- failed
[20:10:35] Starting 'scripts'...
[20:10:35] Finished 'scripts' after 52 ms <- worked
[20:10:53] Starting 'scripts'...
[20:10:54] Finished 'scripts' after 58 ms <- failed

gulpfile.js：

/////////////
// INCLUDE //
/////////////

var gulp = require('gulp');

// Plugins
var autoprefixer = require('gulp-autoprefixer');
var concat = require('gulp-concat');
var rename = require('gulp-rename');
var sass = require('gulp-ruby-sass');
var uglify = require('gulp-uglify');
var expect = require('gulp-expect-file');

// Globals
var jsFiles = ['js/custom1.js',
             'js/custom2.js',
             'js/custom3.js',
             'js/custom4.js',
             'js/custom5.js',
             'js/custom6.js',
             'js/custom7.js',
             'js/custom8.js',
             'js/custom9.js',
             'js/custom10.js',
             'js/custom11.js',
             'js/custom12.js',
             'js/custom13.js',
             'js/custom14.js',
             'js/custom15.js',
             'js/custom16.js',
             'js/custom17.js',
             'js/custom18.js'];

var cssFiles = ['scss/style.scss'];



///////////
// TASKS //
///////////

// FILES
gulp.task('files', function() {
  var files = cssFiles.concat(jsFiles);
  return gulp.src(files)
    .pipe(expect(files));
});

// SCRIPTS
gulp.task('scripts', function() {
    return gulp.src(jsFiles)
        .pipe(concat('script.js'))
        .pipe(rename({suffix: '.min'}))
        // .pipe(uglify())
        .pipe(gulp.dest(''));
});

// SASS
gulp.task('sass', function() {
    return sass(cssFiles, {style: 'compressed'})
        .pipe(autoprefixer({
            browsers: ['last 2 versions'],
            cascade: false
        }))
        .pipe(rename({suffix: '.min'}))
        .pipe(gulp.dest(''));
});

// DEFAULT
gulp.task('default', ['files','scripts', 'sass']);

// WATCH
gulp.task('watch', function() {
    // Watch .js files
    gulp.watch(jsFiles, ['scripts']);
    // Watch .scss files
    gulp.watch(cssFiles, ['sass']);
});

让我想起另一个BUG

两个月前，我遇到了类似这样的错误，只有在手表任务被解雇时才有效。之后，您必须重新启动命令。奇怪的是，在终端中没有任何错误消息，它回应好像它会起作用。但结果是一个空的css文件。

I fixed this OLD issue我将nodejs-installation从0.12.x更新为4.x.x.

但目前的问题似乎有所不同。

Answer 1

从您的日志中，scripts看起来过于频繁，这可能会导致冲突。您是否将连续文件输出到源文件夹，重新启动任务？

.pipe(gulp.dest(''));

如果输出到其他文件夹会怎样？

.pipe(gulp.dest('dist/'));

Answer 2

找到原因和解决方案：

gulp-watch快速启动并在通过FTP上传时执行。

所以gulp-watch不能区分您的上传方法......并且只有在识别出更改时才会触发。而是等到成功上传完整文件。

解决方案是更改FTP客户端的upload-methode，或者只选择另一个可识别此功能的观察者。（目前我使用when-changed *）。

当我在保存时上传文件时，这个事情会翻转两次。这是SFTP似乎部分上传数据的一个很好的指标。所以我现在将阅读如何更改Sublime SFTP中的upload-methode。（这样我就可以再次切换回gulp-watch。

gulp watch - 一个文件 - 只汇总一个文件的一半

2 个答案: