Angular 9 (Ivy) App build with local library (mono-repo) failing #36386
Comments
michaelfaith
changed the title
|
Where is the What is in the Can you try processing the libraries directly using ngcc (running from your project root): |
|
@petebacondarwin thanks for the quick reply. Really appreciate the help. The projects/fabric-components folder has an entry point with just The fab-utilities is just a collection of reusable functions that i have a dedicated endpoint for. They're used in both the app and within the breadcrumbs. And that seems to compile fine in all cases. shared-config just has some shared configuration types, that i'll be adding more to as i move more components over. breadcrumbs currently has the only actual module, as it was my first component to shift over. The index.ts for each just exports everything in the adjacent public-api. Each ng-package just points at the adjacent index as entry point. Here's the output from the ngcc command. Looks like it's reporting invalid entry-point for breadcrumbs: My understanding was that we should use package references like that for imports to other internal classes, rather than relative path imports. |
|
I wonder if this commit might help: 995cd15 You can test it by updating the dep to: |
|
@andreialecu I tried using that compiler-cli, but it immediately throws this error: Do i need to delete all of the @angular dependencies from node_modules and re-install? |
|
Ok, i wiped out the |
|
It does look like ngcc had success with breadcrumbs this time when i manually run the ngcc command @petebacondarwin gave me earlier. However, during the regular ng build (without forcing the ngcc as a postinstall step) it's failiing. |
|
@michaelfaith - I am sorry I have not replied sooner. Did you ever get this working? We have rolled out a number of improvements to ngcc over the last month or two. |
petebacondarwin
added
needs reproduction
|
@petebacondarwin thanks for getting back. I haven't retried it since adding ngcc as postinstall step for the work around. I can try updating to the latest, removing that, and retrying. |
|
@petebacondarwin I updated my project to 9.1.9 and 9.1.7 of core and cli respectively, as well as 9.1.5 of ng-packagr, and it's still happening. It's basically throwing an error for every component/endpoint in the library (except, interestingly, the one component that has an svg template instead of html...). When i first posted this, i tried to recreate it in a small simple mono-repo, with secondary endpoints, but wasn't able to with the simple setup. Many of my components use exported functions or model objects from another endpoint, and i don't think my simple test had that. But some of the components that are failing, don't reference outside of their endpoint, so i'm not sure that that's the defining factor either. I can try to recreate it again in a small simple starter app, but is there anything else that might be helpful i can try within my main project to identify possible root cause? |
|
That would be great! As you can imagine blind-remote-debugging is really hard 😸 |
|
Definitely understand. I tried all morning to recreate this in the little test app i created when i tried the first time. I added two additional endpoints, one for common model and one for reusable functions. Used both in a component in the same library but different endpoints. Used the function in the app too. Added a shared stylesheet that both the library component and app use. Added Angular Material since we're using that pretty heavily. Just trying to emulate the basic usage pattern from our main app as best i can. But alas, no luck so far. Seems to handle it just fine. I'm kind of running out of ideas, since this seems to mirror our approach at a basic level. |
|
I'm sorry @michaelfaith, without a reproduction it is basically impossible for us to resolve your issue. Closing this issue for now. If you come up with a way for me to help, please post here and I will re-open. |
@petebacondarwin After updating to v10, I'm having even more issues, with ngcc not even working now on the --prod built library. I re-ran the debug command you gave, and it seems to be tripping up on endpoints that depend on other endpoints? You can see that the two that it keeps complaining about (common and utilities) compile fine later. So it's like the compiler isn't figuring out the correct order to process the endpoints? It's still the case that if i build the lib with Ivy and run the local app with Ivy, it works. But building the lib with the prod flag and running the local app with Ivy is not really feasible anymore, even with the ngcc postinstall, which solved it with v9. |
|
Have you changed your tsconfig.json setup? What is in your "paths" in tsconfig.json? |
I added this to the tsconfig.base, which both the app and lib tsconfigs extend: I've tested building with the --prod flag and publishing, then pulling in via npm, and that all works great. It's just the local builds of the app if the lib is built with --prod that's failing like this. |
|
Can you try adding |
@petebacondarwin Using the app one didn't seem to produce any different results, but when i used the tsconfig.lib.json from the library folder, that one seemed to process everything correctly, and my app Here are my tsconfigs: tsconfig.app tsconfig.lib |
Unfortunately that doesn't change the behavior. I went back and tried to recreate this in a small demo app, since so much has changed since i tried before. I'm still not able to fully recreate the issue, in that the app build is still working ok in the simple case. But what i am able to recreate in the simple case is that invalid entry-point warning that the ngcc debug run is giving, when an entry-point depends on another. If that's possibly a symptom of the larger issue i'm experiencing with the full app, would it be helpful to share that? I don't understand why it doesn't fail the app build, like it does in the bigger project, though, or why pointing ngcc at my lib tsconfig fixes it. |
|
@petebacondarwin OK! I finally managed to recreate it in the smaller app. The one difference that i hadn't incorporated in the simple case, is that our tsconfig.app is down one level from root, in the src folder. Once i made that change in the small app, the app build stopped working with the --prod built lib. Is it necessary to have that app tsconfig at the root level, or is this something that should be addressed as a bug? |
|
Interesting... When ngcc runs standalone it will try to load When ngcc is run as part of the CLI build, it already knows which tsconfig file is being used and gets the |
|
By the way, @alan-agius4 reminded me that this statement is not correct:
You should never point at the source but at the compiled files. That being said when using |
|
@petebacondarwin, I confirm that. |
|
Thanks so much for explaining that. So, @petebacondarwin, the way you described how ngcc is resolving the Since our paths definition, that maps to the locally built lib, is in The reason we were using --prod on the lib builds was for our ci/cd pipeline. We weren't using it on our local dev machine builds, but for ci/cd we were wanting to run the test app with as close to an apples-to-apples comparison with what was being published. Rather than building the lib one way for testing and then another way for publishing. Building it with --prod for both in ci/cd (with the additional ngcc postinstall) was working ok in v9. But that broke with this update to v10. That forces us to use non-prod builds for our testing steps, which would work, but i think is less than ideal, you know? And it doesn't seem like it was intentional. Anyway, now that i think we may have found the root cause, would it be worth opening a new issue for this, since it's not exactly what this original issue was for? And i could actually provide a test app, if needed. |
|
So I believe that this line ( ) is just copying whattsc would do. In other words, when not provided with an explicit tsconfig file path, it just looks for tsconfig.json in the project directory.
I don't think that is really a bug in our compiler. Instead I think that we should look at where the |
|
So having talked offline to @alan-agius4 - I understand a bit more now. With a solutions-style layout it is no longer possible for any of our compilers:
|
|
Makes sense. I guess i don't fully appreciate the benefits of the solution-style layout, as it is. But i think any of those options would definitely help. The third would probably be best, but obviously require more work to implement. I guess in the interim, sounds like i could either just undo the solution-style layout change, or add the --tsconfig flag to the postinstall ngcc call, which are both viable options. Appreciate all the help figuring this out. I'd like to get to the point where i could actually help contribute changes for stuff like this. Will review your contributing guidelines. |
…onfig In CLI v10 there was a move to use the new solution-style tsconfig which became available in TS 3.9. The result of this is that the standard tsconfig.json, which ngcc (and ngc and tsc) infer if not given a explicit tsconfig file path no longer contains important information such as "paths" mappings, which ngcc might need to correctly compute dependencies. This commit logs a warning in this case to inform the developer that they might not have meant to load this tsconfig and offer alternative options. Fixes angular#36386
…onfig In CLI v10 there was a move to use the new solution-style tsconfig which became available in TS 3.9. The result of this is that the standard tsconfig.json, which ngcc (and ngc and tsc) infer if not given a explicit tsconfig file path no longer contains important information such as "paths" mappings, which ngcc might need to correctly compute dependencies. This commit logs a warning in this case to inform the developer that they might not have meant to load this tsconfig and offer alternative options. Fixes angular#36386
|
Created a PR to log the warning (i.e. 2. from above). |
…onfig In CLI v10 there was a move to use the new solution-style tsconfig which became available in TS 3.9. The result of this is that the standard tsconfig.json no longer contains important information such as "paths" mappings, which ngcc might need to correctly compute dependencies. ngcc (and ngc and tsc) infer the path to tsconfig.json if not given an explicit tsconfig file-path. But now that means it infers the solution tsconfig rather than one that contains the useful information it used to get. This commit logs a warning in this case to inform the developer that they might not have meant to load this tsconfig and offer alternative options. Fixes angular#36386
|
Awesome. Thanks for the quick turnaround. Appreciate it! |
…onfig (#38003) In CLI v10 there was a move to use the new solution-style tsconfig which became available in TS 3.9. The result of this is that the standard tsconfig.json no longer contains important information such as "paths" mappings, which ngcc might need to correctly compute dependencies. ngcc (and ngc and tsc) infer the path to tsconfig.json if not given an explicit tsconfig file-path. But now that means it infers the solution tsconfig rather than one that contains the useful information it used to get. This commit logs a warning in this case to inform the developer that they might not have meant to load this tsconfig and offer alternative options. Fixes #36386 PR Close #38003
…onfig (#38003) In CLI v10 there was a move to use the new solution-style tsconfig which became available in TS 3.9. The result of this is that the standard tsconfig.json no longer contains important information such as "paths" mappings, which ngcc might need to correctly compute dependencies. ngcc (and ngc and tsc) infer the path to tsconfig.json if not given an explicit tsconfig file-path. But now that means it infers the solution tsconfig rather than one that contains the useful information it used to get. This commit logs a warning in this case to inform the developer that they might not have meant to load this tsconfig and offer alternative options. Fixes #36386 PR Close #38003
|
After updating to 10.0.4 for our internal shared library, "ng build" is giving the new warning all the time, even if I explicitly point --tsConfig to the appropriate tsconfig.lib.json. Maybe it was doing the wrong thing before this fix by implicitly referring to the base tsconfig.json, but I don't immediately see a way to make it do the right thing. |
|
@hamfastgamgee What versions are you using exactly? In particular, the CLI version and @ngtools/webpack version is relevant here. |
|
Ah, @hamfastgamgee, I guess that is being built via ng-packagr? |
|
Oh hi Pete! ^^ ng-packagr could be it, yeah, I don't think that's been updated yet. |
|
It still needs to be updated to pass the correct tsconfig path through to ngcc. Similar to what CLI does: |
|
Yeah, I was wondering if ng-packagr needed a corresponding update. I'm going to guess I'm not going to be the only person with this error. My immediate question is: What are the downsides? Do I need to leave my library on 9.1.x until this is resolved, or is it just basically an innocuous warning if everything seems to be working otherwise? (Not sure how much of tsconfig.lib.json ngcc uses.) |
|
If you are not using |
|
But for production (i.e. publishing to npm) there should be no problem since you will not be processing via ngcc. |
|
Also, looking at the ng-packagr code, I see that it is explicitly passing the |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
…onfig (angular#38003) In CLI v10 there was a move to use the new solution-style tsconfig which became available in TS 3.9. The result of this is that the standard tsconfig.json no longer contains important information such as "paths" mappings, which ngcc might need to correctly compute dependencies. ngcc (and ngc and tsc) infer the path to tsconfig.json if not given an explicit tsconfig file-path. But now that means it infers the solution tsconfig rather than one that contains the useful information it used to get. This commit logs a warning in this case to inform the developer that they might not have meant to load this tsconfig and offer alternative options. Fixes angular#36386 PR Close angular#38003
🐞 Bug report
Command (mark with an
x)Is this a regression?
Haven't tested in older version, so i'm unsure, but considering that this is Ivy related, i would imagine it is regression.
Description
I have an Angular 9 app that i'm starting to move some of the components into a dedicated library project, which uses secondary entry points (trying to mimic Angular Material's approach). Everything builds fine if i build both library and app with the Ivy compiler, but if i build both with the --prod flag (which causes the library to be built without Ivy), the app build fails with the following error:
I tried updating to the latest version (9.0.2 -> 9.1.0), but it's still doing the same thing. I tried recreating this with a brand new super simple mono-repo project, but in that simple case it works fine. I compared the tsconfig and angular.json config files between my app and the simple working app, but they're fairly identical. As a last resort, i added
"postinstall": "ngcc"to my root package.json, wiped out my library's folder in my node_modules dir, and re-ran npm install. This forced ngcc to run on everything including my library. After that, the app build worked as it should. So it would seem that the app build isn't recognizing that the library build was done with viewEngine and kicking off the ngcc itself?🔥 Exception or Error
🌍 Your Environment
Anything else relevant?
The text was updated successfully, but these errors were encountered: