-
Notifications
You must be signed in to change notification settings - Fork 1.4k
When watch is triggered build.js.dev displays lots of errors. #1145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hmm...have you changed the glob for the source files that is passed into the TS compiler? Because if it's including all of your source files and it's not cached, I don't see how it could be "missing" a file? The reason that gulp-cached was removed is because it was actually hiding errors. gulp-cached only passes changed files downstream, so the "typed" compile wasn't actually checking things correctly. For example, if you changed a class name, that file might still compile fine, but any other (currently unchanged) files that depended on the old class name would fail to trigger compile errors (because they're unchanged and aren't passed downstream for recompilation). The new setup ensures that errors like that would now be caught. The new |
Also not sure what you mean about |
Thanks for your answer. I did take a look at the wiki, but sadly nothing really new for me there. The reason I mentioned It turns out, it might not have anything to do with that. I did find some new information, I only get this long list of error messages when I change a SASS file and not when I change a TS file. So it is somehow related to the SASS files and only when the watch gets triggered. Tomorrow morning I will check if I can reproduce this with a clean checkout from the seed. |
Well, I made a fresh clone from the seed, but sadly can't reproduce the problem then. |
Could there be some difference between your larger project and the master seed? Something you changed or tweaked that makes it diverge from master? Beyond that, I guess just keep us posted. If you find the cause and it is actually due to the changes I made to the TS compile task, let me know. |
I've kept the changes to the master seed as little as possible (in order to hopefully prevent these kind of differences). I made some minor changes here and there and extended it, but can't think of anything that would affect this. Anyway, thanks for your help! For now I will just keep using the cached version, I can live with that. If I find the cause + solution in the future you will hear from me. |
@brian428 I got the same issue @sjiep have. And found out the same thing:
Like @sjiep, i could not reproduce with the original seed. If i found out the cause i will bring here too. |
Yeah, still no idea how this could have anything to do with SASS. The glob used for the TS source only includes *.ts files (https://github.com/mgechev/angular2-seed/blob/master/tools/tasks/seed/build.js.dev.ts#L24), so this isn't even including HTML or SASS files. |
@brian428, i guessing that the previouly task called by the gulp "build.html_css.ts" (in the watch task) is changing something that the |
Hmm, I don't see how. build.html_css.ts specifies only .html/.css/.scss extensions in it's globs. If you specify a cache key in build.js.dev.ts, does that matter? e.g.: if (typedBuildCounter < TYPED_COMPILE_INTERVAL) { isFullCompile = false; tsProject = makeTsProject({isolatedModules: true}); projectFiles = projectFiles.pipe(plugins.cached('build-js-dev')); util.log('Performing typeless TypeScript compile.'); } else { I don't think it should, but the empty cache key is about the only thing I can think of that could affect anything. |
To solve the issue, between lines 30 and 43 i put the following: let projectFiles = gulp.src(src).pipe(plugins.cached());
let result: any;
let isFullCompile = true;
// Only do a typed build every X builds, otherwise do a typeless build to speed things up
if (typedBuildCounter < TYPED_COMPILE_INTERVAL) {
isFullCompile = false;
tsProject = makeTsProject({isolatedModules: true});
util.log('Performing typeless TypeScript compile.');
} else {
tsProject = makeTsProject();
projectFiles = merge(typings, projectFiles);
}
This way the problem is solved. But i don't know if it has any side-effects. |
Yeah the whole problem is that we don't want the typed compile to be cached, because gulp-cached only forwards changed files downstream. Meaning a change in one file could result errors in other (currently unchanged) files that are not caught because the unchanged files aren't recompiled. What about putting it back the way it was, but removing the use of cached from the untyped build (so that cached is basically not used at all in build.js.dev.ts)? |
@jvitor83 your change is what the code used to do before the pull request by @brian428 got merged. For now I've done a similar thing to 'supress' the error message (strangely even though they are error message, the build just runs fine and does its thing, it's just very annoying that a billion error messages are displayed in the console on every file change). Still am clueless why this is happening, as @brian428 mentioned, SASS has nothing to do with the TS compiler. |
To be clear: does this only occur when using SASS? Everyone who's tried things using a fresh pull of the seed says the problem doesn't manifest (even with SASS enabled, as far as I can tell), so it seems like it's got to be something specific to the projects that are seeing this problem. But what it could be I have no idea. It doesn't seem to make any sense. :-/ |
I indeed can't replicate the problem on a fresh pull of the seed with SASS enabled. For me errors show up when the watch is running and I change a SASS file, not when I change a TS file. I'm not sure if this only happens when using SASS though. I've only used the seed in one project which has SASS enabled. |
Does removing the use of gulp-cached from the isolated module compile (so that gulp-cached isn't used at all in build.js.dev.ts), or adding a cache key to the gulp-cache call in the isolated module compile (e.g. |
My |
Understood, it was just an idea. I guess all we can hope for is a reproducible case then. Use of gulp-cached in the TS compile was going to come out anyway (for the reasons already mentioned), so it sounds like this would have affected you no matter what. But I'm still totally baffled as to how anything in the TS compile task could be affecting (or be affected by) the SASS task... |
Not sure if this is the same, but I got similar error messages. Just found this issue because I noticed the "double" path
|
Sounds like a separate issue. Check out #1157 and ivogabe/gulp-typescript#307. |
@brian428 Recently I merged the latest changes from the seed into my project. Out of curiosity I removed my line that cached the project files on a typed build to see if the warning/error messages still appeared. And behold, they didn't show up any more! So from my side, I can't reproduce my error any more. |
Great, sounds like this can be closed then. Given what you said, it sounds like the issue was likely with one of the dependent libraries rather than the seed itself. |
I am having this issue after angular2-seed update rc6. |
Uh oh!
There was an error while loading. Please reload this page.
Since I merged the pull request of #1099 I get the following type error messages from the
build.js.dev
task, when I havenpm start
running and make a change in the code which triggers thewatch
to re-execute the given tasks.(This errors shows up for basically every TS file it compiles.)
After a bit of debugging I found out this is happening because the projectFiles are not cached any more on the typed builds, see build.js.dev.ts#L30.
For now I have added the line
projectFiles = projectFiles.pipe(plugins.cached());
to my typed builds as well such that the errors don't show up any more.In my debugging I found out that on the first run of the
npm start
tasks there is nosourceRoot
specified in thetsProject
variable. However on every new 'watch execution' thetsProject
contains asourceRoot = APP_CLIENT
entry, I believe this should actually beAPP_BASE
instead.@brian428 any idea why this is happening? Can you replicate this behaviour?
The text was updated successfully, but these errors were encountered: