Angular-cli: [v1.5] ng build doesn't work with `noEmit`

[lacolaco]

Bug Report or Feature Request (mark with an x)

- [x] bug report -> please search issues before submitting
- [ ] feature request

Versions.

    _                      _                 ____ _     ___
   / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
  / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
 / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
/_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
               |___/

Angular CLI: 1.5.0
Node: 8.5.0
OS: darwin x64
Angular: 5.0.0
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

@angular/cli: 1.5.0
@angular-devkit/build-optimizer: 0.0.32
@angular-devkit/core: 0.0.20
@angular-devkit/schematics: 0.0.35
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.8.0
@schematics/angular: 0.1.0
typescript: 2.4.2
webpack: 3.8.1

Repro steps.

• ng new
• open tsconfig.json and add "noEmit": true
• ng build

The log given by the failure.

No error logs are shown but bundled js files are clearly broken. too small!

Date: 2017-11-02T08:04:03.438Z
Hash: ee253d778b0f6e79b7e3
Time: 5256ms
chunk {inline} inline.bundle.js, inline.bundle.js.map (inline) 5.83 kB [entry] [rendered]
chunk {main} main.bundle.js, main.bundle.js.map (main) 303 bytes [initial] [rendered]
chunk {polyfills} polyfills.bundle.js, polyfills.bundle.js.map (polyfills) 323 bytes [initial] [rendered]
chunk {styles} styles.bundle.js, styles.bundle.js.map (styles) 11.3 kB [initial] [rendered]

generated main.bundle.js

webpackJsonp(["main"],{

/***/ "../../../../../src/main.ts":
/***/ (function(module, exports) {



/***/ }),

/***/ 0:
/***/ (function(module, exports, __webpack_require__) {

module.exports = __webpack_require__("../../../../../src/main.ts");


/***/ })

},[0]);
//# sourceMappingURL=main.bundle.js.map

Desired functionality.

I think there are 2 solutions for this.

1. enforce noEmit = false in AngularCompilerPlugin (ignore tsconfig's setting)
2. Emit error log if noEmit is turned on

the current behavior is very difficult to find the reason for app crashing silently.

Mention any other details that might be useful.

[lacolaco]

Historically, many developers added noEmit into their tsconfig.json for debugging. This issue is not a corner case, I think.

[filipesilva]

According to https://github.com/Microsoft/TypeScript-Handbook/blob/master/pages/Compiler%20Options.md, setting noEmit to true means that outputs will not be emitted.

So when you set it, nothing is being emitted for main.ts. This seems correct to me.

What behaviour did you expect instead of this?

[lacolaco]

@filipesilva Until v4, noEmit is ignored by Angular CLI's build process.
This is changed behavior. It can be a kind of breaking change for developers trying to update Angular from v4 to v5.
Possibly previous behavior was wrong, but now, there is a change actually.

My expected behavior is as the below.

1. Enforce noEmit = false in AngularCompilerPlugin (ignore tsconfig's setting, same to v1.4)
2. Emit error log if noEmit is turned on

1 is easy to implement because one line change is needed. 2 is a bit complex. I prefer enforcing noEmit = false.

[filipesilva]

I agree that the behaviour changed, but would say that this is a bug fix. I mostly consider breaking changes to only apply to features we have or public APIs we expose. Ignoring noEmit is not a feature we had, but rather an unfortunate side effect.

There are situations where a bugfix we made negatively affected a lot of people and so we revert it to avoid causing trouble to users, and try to find another fix. But we only really do that on extreme cases. I think in this case it really is correct to respect that option.

We've improved our parsing of tsconfig options and that means the behaviour should change - it should be more correct. For those reasons I don't think any action should be taken and that the current behaviour is correct.

[lacolaco]

@filipesilva I understand that is a bugfix and the current is correct. So could you write a caution at somewhere about improving tsconfig parsing and its effects? If CHANGELOG.md existed I could send a PR for that, but isn't.

[filipesilva]

We do mention it in the blogpost: https://blog.angular.io/version-5-0-0-of-angular-now-available-37e414935ced#148d, and in the release we ask users to see the blog post.

We’re also updating the way we use .tsconfig files to follow TypeScript standards more strictly.

[lacolaco]

I've felt that is not enough information, but it is mentioned actually. I understood.
Thank you so much.

[Tragetaschen]

This change is really, really annoying: Until now, I was able to convince VS not to generate a bunch of useless *.js file throughout my entire directory structure when building the project by setting noEmit in the tsconfig and loaders like awesome-typescript-loader ignore that flag for the compilation.

Now, I can either have great tooling or a working webpack build process.

@filipesilva That quote (and the remaining paragraph around it) as an example for where you documented this breaking change sounds to me more like a taunt than good reasoning and I'm quite angry about that.

I'm also not convinced that this is the way noEmit was meant to work. For me, that flag always meant: don't write transpiled js files to the disk. No matter how hard I try, I'm not able to figure out an actual use case for the current no-emit-behavior of ngtools. The net result (an empty entry module) is never correct.

[filipesilva]

@Tragetaschen what is creating those JS files? Angular CLI doesn't create any JS files but maybe you have something else creating them.

You can also set different options in the base tsconfig.json and on ./src/tsconfig.app.json (the latter being the one that's used by Angular CLI for your app). For instance, you can have "noEmit": true on tsconfig.json and "noEmit": false on ./src/tsconfig.app.json. The base tsconfig.json is there for the editor which sounds like your usecase.

[Tragetaschen]

@filipesilva As I wrote: Visual Studio's build process does this as default behavior for TypeScript files. This can only be disabled via tsconfig (one of the few options not available in Msbuild). Since I still want proper tooling support, I'm out of luck.

Using a separate tsconfig is what I do now.

Still, for the sake of some definition of "correctness", you silently break an entire build process. All other TS loaders for webpack get this right...

[filipesilva]

I'll reopen then, maybe this is a very common scenario but just one that I haven't ran into very often.

[Tragetaschen]

It's still closed, though :)

[filipesilva]

My bad, sorry!

[zoharyosef]

It was indeed very hard to find why the CLI builds nothing, with no error message or anything,
Now I set "noEmit" to false on "tsconfig.app.json" and it works without side effects.
Thanks.

[montanha913]

Any updates on this issue? This seems to be preventing a Hybrid application to work, and setting "noEmit" to false or following the steps described here (https://github.com/Microsoft/TypeScript/wiki/FAQ#why-am-i-getting-the-error-ts5055-cannot-write-file-xxxjs-because-it-would-overwrite-input-file-when-using-javascript-files) didn't seem to work.

[alan-agius4]

Hi all, we feel that we need a stronger argument in order to introduce more code to maintain and a breaking change.

We already support tsconfig inheritance so one might as well configure different flags in different ts configs and one of them can be noEmit: false.

In case we are missing something or there is a use case which cannot be done via tsconfig inheritance. Kindly open a new issue explaining this.

Thank you all for your understanding.

[angular-automatic-lock-bot[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._}