Skip to content
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

Projects with Declaration=True in tsconfig will not run #1731

Closed
randyaa opened this issue Aug 17, 2016 · 12 comments
Closed

Projects with Declaration=True in tsconfig will not run #1731

randyaa opened this issue Aug 17, 2016 · 12 comments
Labels
P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent type: bug/fix

Comments

@randyaa
Copy link

randyaa commented Aug 17, 2016

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
Copy link

What are you trying to accomplish by this?

@randyaa
Copy link
Author

randyaa commented Aug 17, 2016

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
Copy link

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
Copy link

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

@randyaa
Copy link
Author

randyaa commented Aug 17, 2016

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
Copy link

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
Copy link
Contributor

deebloo commented Aug 18, 2016

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
Copy link
Author

randyaa commented Aug 19, 2016

@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
Copy link
Contributor

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 ?

@filipesilva filipesilva added type: bug/fix command: build P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent labels Aug 23, 2016
@TheLarkInn
Copy link
Member

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

@filipesilva
Copy link
Contributor

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

@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 7, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent type: bug/fix
Projects
None yet
Development

No branches or pull requests

5 participants