Link to my TypeScript TS2307 modules error: cannot find the module

Question

I am working with aurelia-typescript-skeleton as the base for my new project. I tried adding a new hello.ts file to the src folder

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

and refers to it in another file in the same folder as below

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

Both files are on the same level. Everything works fine when I build for the first time. When I make any subsequent changes to the users.ts file, compiling gulp-typescript continues to fail with an error that I cannot understand. Typescript compiler error

 > 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 

Whenever I make a new gulp watch , there are no errors. The error appears when I edit / modify the users.ts file. Can someone help me understand this error? It must be something basic ...

I am in a Windows 7 environment and I am getting this error on two machines.

UPDATE:

Below is the repo to reproduce the problem . Steps to play:

• Clone repo, install all npm and jspm .
• Running gulp watch -> there are no errors for me
• Modify the users.ts file and save -> error.

UPDATE2:

Adding a clean step to the build-system helps avoid the problem. Here is the link to commit . However, I am not sure about the actual cause of the problem first hand.

Answer 1

This is because only users.ts , the modified file, is sent to the subsequent TS compilation, and noResolve included (in tsconfig.json ).

See file build/tasks/build.js , task 'build-system' :

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

Which files are changed is determined ( gulp-changed ) by comparing the last modified time of the input files with the destination. Therefore, when you run clean or watch , which include clean , the destination is cleared, and all files are sent again for compilation, so there are no errors.

As the updated skeletal application (1.0.0-beta.1.2.2) is updated, this problem is fixed.