Plik Gulp, który wydajnie kompiluje tylko zmienione pliki TypeScript

Question

Próbuję sprawić, żeby gulp skompilował i oglądał pliki TypeScript. Oto, co do tej pory dostałem.

var tsProject = plugins.typescript.createProject(
{ 
    removeComments: false, 
    target: 'ES5', 
    module: 'amd', 
    noExternalResolve: false, 
    noImplicitAny: false, 
}); 

var typescriptGlob = [ 
    presentationScriptsDir + '**/*.ts', 
    definitelyTypedDefinitions 
]; 

gulp.task("compile-typescript", function() { 
    return gulp.src(typescriptGlob) 
     .pipe(plugins.typescript(tsProject)) 
     .pipe(gulp.dest(presentationScriptsDir)); 
}); 

gulp.task("watch-typescript", function() { 
    return gulp.watch(typescriptGlob, ["compile-typescript"]); 
}); 

Używam gulp-typescript.

Ponieważ jednak mamy setki plików TypeScript, nie chcę przekompilowywać wszystkich plików za każdym razem, gdy jedna z nich się zmieni. Powyższy kod robi (mogę powiedzieć bo watch-typescript trwa co najmniej tyle czasu, ile na compile-typescript)

Próbowałem, używając gulp-changed, jak to

gulp.task("compile-typescript", function() { 
    return gulp.src(typescriptGlob) 
     .pipe(plugins.changed(presentationScriptsDir, {extension: '.js'})) 
     .pipe(plugins.typescript(tsProject)) 
     .pipe(gulp.dest(presentationScriptsDir)); 
}); 

To rzeczywiście filtruje pliki niezmienione. Ale wtedy kompilator maszynopisów zgłasza błędy, ponieważ otrzymuje tylko jeden plik, w którym brakuje deklaracji typów, które normalnie pobiera z innych plików.

Nie chcę ustawiać flagi noExternalResolve na wartość true, ponieważ wtedy wiele sprawdzeń typów nie zostanie wykonanych, co w pierwszej kolejności powoduje wiele przyczyn używania TypeScript.

Jak mogę lepiej napisać ten plik gulp?

Answer 1

Kompilator TypeScript nie przechodzi osobnych faz kompilacji i łączenia, jak ma to miejsce w przypadku większości kompilatorów języków. Tak naprawdę nie można wykonać przyrostowej kompilacji.

Tak jak powiedziałeś, aby uzyskać sprawdzenie typu, kompilator musi załadować i przynajmniej ponownie przeanalizować wszystkie pliki, które mogą być przywoływane.

W naszym projekcie wykorzystaliśmy wsparcie Visual Studio do "Kompilowania przy zapisie", które wygeneruje dla nas pliki .js podczas opracowywania i debugowania. (Wygląda na to, że ten mechanizm korzysta z funkcji noExternalResolve). Następnie polegamy na naszym procesie testowania jednostkowego i serwerze ciągłej integracji, aby uruchomić zwykłą kompilację TypeScript, aby uzyskać wszystkie błędy składni i literówki.

Proponuję więc uruchomić zegarek z flagą noExternalResolve, ale także uwzględnić krok w przepływie pracy, aby uruchomić pełną kompilację TypeScript w ważnych momentach. Może możesz określić konkretny plik "root", który rozpoczyna pełną kompilację, gdy zostanie zmieniony, lub możesz znaleźć inne zdarzenie, które nie pojawia się zbyt często, aby użyć zwykłej kompilacji.