yes, our team also manages our opennext
yes, our team also manages our opennext integration, what's the question/issue? 🙂
14 Replies
Ah cool! I created an issue 2 months ago, in the opennextjs/opennextjs-cloudflare repo, but havent gotten any feedback, so I'm wondering if that repo is the wrong place to post issues? 🙂
It's https://github.com/opennextjs/opennextjs-cloudflare/issues/760, essentially the
Env typing was colliding in the opennext build if I had a service binding to another worker with types setup properly.That is the right repo for issues 🙂👍
Sorry for the issue not having been looked thus far, there aren't many engineers working on the open-next adapter and currently there are some high priority things that we're trying to address (specifically performance issues)
Gotcha, that's perfectly understandable. Thanks Dario!
anyways I just read your issue, are you sure that it is an open-next issue? does the same not apply when you use standard workers? 🤔
Nope, it's the next build that fails. So something in the next build pipeline is wonky with the worker types. I have 3 workers, 2 of them work fine together
The third (opennext) is the problem. I've tried to do the exact same binding just to verify, and got no issues between two TS workers
I see 🤔
I'll try to have a look
my repro repo should still be valid, but it's not changed since 2 months ago!
ah... by the way... does disabling the Next.js typescript checking help?
next.config.js: typescript | Next.js
Next.js reports TypeScript errors by default. Learn to opt-out of this behavior here.
I believe I tried to do that, but it also failed... But my memory might fail me here. Can check!
(
ignoreBuildErrors)
if you can that could be helpful, but I also can when looking into it 😄👍
did indeed solve the problem! Or well, works as a workaround. I think what I remember trying is to exclude the other worker in the tsconfig, which didn't work. So must have not tried this.
But then we lose all type safety during build, which perhaps is not the best 🙂 Could possible build a CI/CD pipe that has a manual typecheck step, but that still gets the type error from the other worker 🙁
Right now my workaround is to NOT type the worker and just call
.fetch to it, building a manual requestyeah I mean, ignoring the typescript at build is not really a good solution, I was just wondering where in the process fails 🙂
Rest of next build succeeded with
ignoreBuildErrors: true 👍