@dorilama FWIW here is the log - I am just super curious about how dependencies are … “(cached)”.
This vue-tel-input WAS previously used - but removed. No longer in the app in any way. (I will have Charles triple check other dependencies per your comment when he wakes up) - so just wondering if there is some way that WeWeb is trying to install from cache vs what’s actually in the app?? (and how does / could this cache be cleared??)
@dorilama redirects this thread and saves the day - that’s what makes this community great!
After AI is launched, if anyone from the WeWeb team wants to discuss an enterprise plan sale, you have a hot lead here. 
I sure as hell would like to discuss it with WeWeb team.
well … my day isn’t saved yet. I basically have 24 hours to find a way to deploy. But yeah … @dorilama is the kind of guy any community is lucky to have. I wish we could copy and paste him.
the official weweb team is here in the community and they are doing the heavy lifting every day.
I am just a guy spotting a bug I can’t directly explain and an opportunity to learn more about this platform.
It takes a village.
how deps are cached is specific to weweb build system (the cloud one).
usually a fresh build starts from scratch and installs everything again. I wonder if you could manage to build the app on your machine. unless the component with the conflicting peer dependency is used somwhere in the project
I feel your pain with a deadline looming.
Just a random thought with no technical insight as to why it may work, but have you tried duplicating the project?
I think this is an impossible case, but… If it’s set to @latest in package.json, it could be that it got updated? So a bump down of a version to a stable old version might solve the issue? Or switching to an older version in general.
Also for the cache, if they changed a version in the package.json, re-installed by deleting the package-lock and re-built the custom component, this could invalidate the cache and maybe unstuck this?
it happens because the dep is declared like this: vue-tel-input@^9.1.3. previous build probably installed v9.2.0 while last build installed v9.3.0 that was published 2 days ago. both versions depend on vue@^3.5.4 but the last one moved it from dependencies to peerDependencies. I suppose that as a dependency it was replaced by weweb dependencies but as a peerdependency it doesn’t and you get the error.
So, if this is the case, how would we resolve the error? Charles has audited every single dependency and dependencies of those dependencies used our customer components - and Vue-tel-input is not used anywhere anymore in any component.
Hi - I have been following the community for some time now for product evaluation purposes - just curious, was this issue resolved??
And we are BACK!
My most sincere gratitude to @Marc @Joyce and the WeWeb team for getting this resolved in the nick of time.
I do look forward to speaking with anyone on the team about Enterprise Support and the support roadmap in general - as I’d love to offer any/all of my ideas and feedback.
Special thanks to @dorilama for just keeping me laughing behind the scenes and reassuring me it would get resolved.
LFG!!!
I’m happy to see the issue was solved with the help of weweb team working with yours. 
Awesome to hear! 
I too would be interested in discussing an Enterprise plan. 
So there’s really no answer here at all about the concerns about support. I’ve got two tickets that are sitting in awaiting for fix. One of them could definitely be tossed but that’s only cause we waited a month or so before we had to change the issue cause we can’t just leave it there hoping support gets back to us. Now again it’s been a month, I know it was holidays but at this point, I don’t expect any support for them. Which is extremely disappointing I recommend this platform to people that create custom software for businesses, but I don’t think I can do that anymore if this is the type of support we get.
@ryanev Hi Ryan, are you currently using Weweb to build our your web app?
