Type checker replacements

[filipesilva]

No description provided.

[alan-agius4]

Wouldn't the below result in the same test?

let errorAdded = false;
runTargetSpec(host, browserTargetSpec, overrides, DefaultTimeout, logger)
  .pipe(
    tap((buildEvent) => expect(buildEvent.success).toBe(true, 'build should succeed')),
    tap(() => {
      // Introduce a known type error to detect in the logger filter.
      if (!errorAdded) {
        host.appendToFile('src/main.ts', 'console.log({}.prop);');
        errorAdded = true;
      } else {
        expect(logger).toContain(expectedError);
      }
    }),
    tap(() => {
      expect(logger).not.toContain(unexpectedError);
      logger.clear();
    }),
    take(2),
  ).toPromise().then(done, done.fail);

[filipesilva]

No, because the type checker logs are not synchronized with builds. Since the type checker runs separately, it will finish rebuilds separately from the main webpack process.

In this specific case, the type checker rebuild will take longer. We need to start a build and and rebuild on the main compilation process, then wait for the forked process to send logs messages.

[alan-agius4]

Ah cause it runs in a forked process. 👍 Cool test with the race :)

[alan-agius4]

Converting circular structure to JSON
    at JSON.stringify (<anonymous>)
    at new Server (/tmp/angular-cli-e2e-11892-90-1lxtz35.zgki/test-project/node_modules/karma/lib/server.js:65:41)
    at Observable.rxjs_1.Observable.obs [as _subscribe] (/tmp/angular-cli-e2e-11892-90-1lxtz35.zgki/test-project/node_modules/@angular-devkit/build-angular/src/karma/packages/angular_devkit/build_angular/src/karma/index.ts:102:29)
 

Looks like you shouldn't pass the logger to karma.

[filipesilva]

@alan-agius4 I think it's not the logger since karma doesn't import it directly, but rather the circular dependency between the type checker and compiler plugin introduced by the new message. I'll refactor the messages into a separate file.

[clydin]

There's a more fundamental issue with the forked type checker. It directly accesses the file system whereas the actual build uses the webpack file system (and host augmentations from within the plugin). The forked type checker should ideally have a custom compiler host that uses IPC to request file content from the main process to ensure the same content is used to type check and build.

[filipesilva]

@alan-agius4 ran some debugging on the circular object reported by Karma and indeed it's the logger property inside the AngularCompilerPlugin instance.

@clydin that's probably the best approach, yeah. Unsure of the limitation on Node's child process IPC channel used here for logging (https://nodejs.org/api/child_process.html). I think it's very likely that the main thread is blocked transferring large files. Doing that properly is essentially a virtual FS server, something that I discussed with @hansl in the past. Not transferring unchanged files is very important in that scenario too.

[filipesilva]

Blocked on karma-runner/karma#3154

[alan-agius4]

LGTM.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}