Change declare export to export declare#78
Conversation
|
Oh wow, that is... something haha i even remember looking up the right order and not seeing a right/wrong answer. I'll take a look and make a release with the fix. Out of curiosity, you mention you use a modified version. Would there be something that could be changed in the module so you wouldn't have to use a copy? |
|
In my environment only the backend server can reach the gql endpoint, so I commented out everything that exposes the gql interfaces on the Vue frontend. I only need nitro to work. I also had to add an extra flag to change which api token gets used based on if a user is logged in, their token has more privileges, and the server has its own api key. I had to do some other things that I can't remember off the top of my head, but I'll take a look tomorrow. |
|
Ya know, in all reality, some of the changes I made could totally be done in other ways. The major changes I made are related to the fact that I didn't actually want endpoint generation at all, because I am not using it as a middleware for my frontend to make requests. I am solely using for my backend to fetch data, and do a lot of transformations to that data. Yes, technically, I could probably implement that with some onResponse logic and check each endpoint, but that fails when I need to use the same gql request for 2 different api requests that do different things with the data. I could make copies of the gql queries with different names, Some of my api endpoints make a gql request, then make a second request based on the response of the first, which means I have to use the server utilities anyway, etc etc... so in the end, setting up on response handlers to build my api felt like more work than just creating my own api endpoints, which I would have to do for some things anyway. So the major changes that I made for my environment are I disabled the composables for the front end only and left the server utilities active (would be simple to split the options into 'includeComposables' and 'includeServerUtils'). Then I completely commented out the server handlers, and I refactored the server utils to call doGraphqlRequest directly instead of performRequest. On top of the fact that it makes everything work even if the endpoint doesn't exist, as far as I can tell, there is nothing that the extra fetch call is doing that couldn't be done directly in the server util handler, so it just saves the extra fetch call (which nuxt afaik wouldn't make a network request for anyway, because its smart enough to know the endpoint is already in the same serverside context). |
|
Ahh I understand. Indeed, the In any case, I can see this being a valid use case that could be added in the module. I created a new issue for that in #79 |
|
Ill mess around a bit more with my setup and see if I come up with something I can merge back. It'll take me a bit as I have another area I'm working on atm. I think it would be possible to make the changes to make a true "server only" option that removes anything unnecessary without fully bastardizing it the way I have currently 😅 |
2 participants
Ok, look. I know this is going to sound absolutely crazy. I am not overexaggerating when I say I have spent the last 14 hours trying to figure this bug out.
I spent some time upgrading my project to Nuxt 4.2 from 4.0.1, and had one major issue. Shadcn kept throwing "[@vue/compiler-sfc] Failed to resolve extends base type." errors everywhere. Now, this is a pretty well documented error, and there are a handful of know solutions to it. It happens when the vue compiler is trying to parse a base type or interface that contains some kind of dynamic or inferred property that is then extended. Shadcn extends types coming from reka-ui, but doesn't have any dynamic inferring types that should cause this issue.
Additionally, because I was having this problem in my fairly large project with lots of dependencies, I wanted to try and solve it in a smaller reproduction. One small problem.
I could not reproduce it.
I spent hours in a clean repo tweaking every config to replicate something similar to my larger projects environment, but nothing worked. So I started adding packages and modules. One at a time. Until finally, in a final hail Mary, one module I never would have expected instantly caused the bug.
That's weird... WHY ON EARTH would graphql-middleware cause a bug in SHADCN?!
So, pulled the repo down and added it as a local module and started commenting out code. As soon as I commented out
helper.addTemplate(template)andcollector.addTemplate(template), everything worked again! (except for the gql middleware). And so began the slow process of removing and re-adding each template until I figured out these 4 were causing issues. If any one of them was active, bug happened.ngl, I read over each file and couldnt figure out what was different between them and the others... until I asked copilot, which said "These are the only 4 files that use 'declare export const' in their definitions. Try swapping it to 'export declare' instead."
And sure as shit, that worked.
Typescript doesn't care about the order of the keywords, they mean functionally the same thing either way. But apparently the vue compiler very much cares, because it starts breaking other things.
Ok, just had to get that off my chest. My head hurts now. Thanks for the great module! I use a modified copy that only provides the server side functions because I don't need gql on the client. This is one of the only gql modules I found that has solid, reliable nitro side bindings, so I appreciate that.