Projects with Declaration=True in tsconfig will not run

[randyaa]

OS?

Windows 7

Versions?

angular-cli: 1.0.0-beta.11-webpack.2
node: 6.3.1
os: win32 x64

Repro steps?

ng new projecta
ng g component ComponentXYZ
edit src/tsconfig.json & set "declaration": true,
ng serve / ng build

The log given by the failure?

When running ng serve the failure looks like:

Unhandled Promise rejection: Failed to load app.component.html ; Zone: <root> ; Task: Promise.then ; Value: Failed to load app.component.html

When running ng build the directory structure looks like:

dist
|   index.html
|   inline.js
|   inline.map
|   main.bundle.js
|   main.map
|   polyfills.bundle.js
|   polyfills.map
|
\---src
    |   main.d.ts
    |   polyfills.d.ts
    |
    \---app
        |   app.component.d.ts
        |   app.module.d.ts
        |   index.d.ts
        |
        +---component-xyz
        |       component-xyz.component.d.ts
        |
        \---environments
                environment.d.ts
                environment.dev.d.ts

Mention any other details that might be useful.

changing template references from

  templateUrl: 'app.component.html',

to

  templateUrl: './app/app.component.html',

seems to correct the issue but this doesn't seem right.

[LunicLynx]

What are you trying to accomplish by this?

[randyaa]

We have a component library we've been using CLI to maintain since cli version 0.0.34 (i think?).

That library has a demo-app that we run locally (and also build/deploy).
It also has a number of components that we build/publish as a component library.

[LunicLynx]

I suspected that. I tried that too, this usecase does not seem to be supported with the webpack based cli anymore.
In part because with webpack, you wan't bundeling at the last step to effectivly use tree-shaking. So my advice would be just use another technique, git sub modules and npm packages with just the source in them worked for me quite well.

[LunicLynx]

But i would also like something like "ng new-lib " to easily build libraries.

[randyaa]

Sure i mean that sounds great but in the mean time the template reference errors seem to be a bug/issue to me especially given that we've been able to chug along with no problems until now with the same approach.

I also don't even understand how the 2 correlate (declaration=true & not being able to find the templates using the normal path).

There definitely seems to be an issue of SOME kind.

[LunicLynx]

with webpack you have to require the templates of libraries like so:

@Component({
    selector: 'some',
    template: require('./some.component.html'),
})
export class SomeComponent  { }

Watch that you don't have a moduleId and use template and not templateUrl.

[deebloo]

if you want to create a library you could also just use the cli for generating and testing and then use plain 'ol typescript to build you dist.

[randyaa]

@deebloo I think this is what i'm going to be stuck with for now but it feels like the CLI shouldn't completely break just because we're emitting declarations? Material2 went back to using gulp most likely because of some of the same things i'm running into : angular/components#948

Seems like a step backwards if this new direction is only good for running/deploying when the old direction worked so well for everything?

[filipesilva]

It's true that we don't yet support the lib option, but I agree with @randyaa that it shouldn't mean that changing the declaration property in tsconfig.json should result in an error.

This seems related to https://github.com/TheLarkInn/angular2-template-loader, can you have a look @TheLarkInn ?

[TheLarkInn]

This is due most likely because of the way awesome-typescript-loader works. TheLarkInn/angular2-template-loader#19

[filipesilva]

I just checked and it seems that adding "declaration": true doesn't break the build anymore. Library support is being tracked in #1692.