Błąd odwołujący się do moich modułów TypeScript TS2307: Nie można znaleźć modułu

Question

Pracuję z aurelia-typescript-skeleton jako bazą dla mojego nowego projektu. Próbowałem dodanie nowego hello.ts plik w folderze src

export class Hello { 
    sayHello(name:string) : string { 
    return 'Hello ' + name; 
    } 
} 

i odwołuje go w innym pliku w tym samym folderze co poniżej

import {Hello} from './hello'; 

export class Users { 
    constructor() { 
    console.log(new Hello().sayHello('Test')); 
    } 
} 

zarówno pliki są na tym samym poziomie folderu. Wszystko działa dobrze, kiedy buduję po raz pierwszy. Kiedy wprowadzam kolejne zmiany w pliku users.ts, kompilacja gulp-typescript wciąż kończy się błędem, którego nie mogę zrozumieć. Błąd z kompilatora maszynopis jest

> Starting 'build-system'... 
> src\users.ts(4,21): error TS2307: Cannot find module 'hello'. 
> TypeScript: 1 semantic error 
> TypeScript: emit succeeded (with errors) 
> Finished 'build-system' after 950 ms 

Ilekroć zrobić świeżego gulp watch, nie ma żadnych błędów. Błąd pojawia się, gdy edytuję/zmieniam plik users.ts. Czy ktoś może mi pomóc zrozumieć ten błąd? To musi być coś podstawowego ...

Jestem na środowisku systemu Windows 7, i otrzymuję ten błąd na 2 komputerach.

UPDATE:

Oto repo to reproduce the problem. Kroki prowadzące do odtworzenia:

1. sklonować repo zainstalować wszystkie npm i jspm zależności.
2. Uruchom gulp watch -> nie wystąpią żadne błędy
3. Zmień plik users.ts i zapisz -> wystąpił błąd.

Update2:

Dodawanie krok clean przed build-system pomaga uniknąć problemu. Oto the link to commit. Nadal nie jestem pewien co do rzeczywistego powodu problemu z pierwszej ręki.

Answer 1

To dlatego, że tylko users.ts, zmieniony plik, jest wysyłany do kolejnej kompilacji TS, a noResolve jest włączony (w tsconfig.json).

proszę zobaczyć plik build/tasks/build.js, zadania 'build-system':

.pipe(changed(paths.output, {extension: '.js'})) 

Jakie pliki są zmieniane są ustalone (przez gulp-changed), porównując czas ostatniej modyfikacji plików wejściowych z przeznaczenia. Tak więc po uruchomieniu clean lub watch, które obejmują clean, miejsce docelowe jest czyszczone, a wszystkie pliki są ponownie wysyłane do kompilacji, więc nie ma błędu.

Podczas próby zaktualizowanej aplikacji szkieletowej (1.0.0-beta.1.2.2) ten problem został naprawiony.