feat(@angular-devkit/build-ng-packagr): permit to set a custom TsConfig file #750
Conversation
permit to use a custom tsconfig.json file by setting its path with a new tsConfig option
ngPackagr may leave some .ng_pkg_build files after an error we may encounter this kind of errors when contributing to build_ng_packagr
Use the new tsConfig option in order to set a custom tsconfig file for the 'work' test this example show how to change the ES level in lib and target all the other options are required for now if we don't want to break the build their should be removed once / if ng-packagr/ng-packagr#786 is released
|
The flaking test (css rebuilds) already has a 2 minute timeout. |
|
I pushed the last git "build" commit just in order to test if it works. Will move it to another PR if ok. |
|
@clydin oh, ok, sorry I didn't saw that. Is there something I could do then ? Do you think some of my code break the tests on appveyor for some reason ? |
|
It's not your code. It appears to be a resource issue with AppVeyor. As long as it is only that one particular test, you can ignore it for now. |
|
Oh this is really nice, I didn't know I'm a bit worried about the mandatory options but that seems like it can go away in the future. Also wondering if we should also generate a tsconfig when making a library. That would avoid having the linting tsconfig which kinda bothered me as well. WDYT? |
|
@clydin Ok so it's non of my business, I'll just delete this commit then ^^ I was worried that the ❌ could make you think that some PRs doesn't deserve review 😄 |
| const ngPkgProject = projectNgPackagr.ngPackagr() | ||
| .forProject(packageJsonPath); | ||
|
|
||
| if (options.tsConfig) { |
There was a problem hiding this comment.
@filipesilva (about your first concern) except if I didn't tought about something, the tsConfig is not mandatory (you can see that the tests doesn't fail after the first commit), given that I first test if it's set before using it in the ngPackagr. Did I forgot some "optionnal" config somewhere ?
|
@filipesilva (about your second concern) I don't think that adding a tsConfig by default would be a good choice, given that ngPackagr do a lot of custom things with it. For now, there is still some issues with that (see ng-packagr/ng-packagr#786) so I don't think it's recommanded to use custom tsConfig except you really need it (like in the example in the tests). @dherges ? FYI : I was already thinking about adding a --tsconfig option to the library schematics with a next PR, but it would realy just be "cherry on the cake", so not a priority |
|
and also @filipesilva "Oh this is really nice" 🎉 thanks a lot |
|
When I mentioned the mandatory options I mean the ones inside the tsconfig (as per the issue you linked), not in the builder here. The option you added is optional and stuff works if we don't add a tsconfig. So yeah, I think what you added in this PR is ideal for now. Later maybe we can reconsider the tsconfig in a newly generated library. |
|
Thanks for adding this option! |
|
Some additional info / clarifications: therea re several places in ng-packagr where a tsconfig is generated. Summarized:
|
Add a new tsConfig option in order to permit to use a custom tsConfig file when using @angular-devkit/build-ng-packagr as a build target in angular-cli.
This is, for example, needed in order to resolve this kind of issue :
See the evolution of tests for an example. This example show how to change the ES level in lib and target
All the other options are required for now if we don't want to break the build. I will remove them and bump the ng-packagr dependency version in another PR once / if ng-packagr/ng-packagr#786 is released
No breaking change.