Ouch yeah- that’s exactly the problem I hit that jfrolich even identified. My sleuthing sadly didn’t take me to the Rescript Compiler project, so that’s not a very discoverable location.
So is there a workaround? I think my code is fine with dropping the few instances where I was using @deriving, but losing jsConverter is annoying- that’s a great little helper.
Not entirely sure, but i think you’d need to downgrade to an older graphql-ppx version for now… your issues came up with the latest upgrade, right?
Yes, I can just not upgrade it- the PR’s still waiting. Is there a plan to somehow resolve this in the future? The linked ticket was closed out pretty quickly so I’m not sure what the official recommendation is.
Thanks to @fakenickels I found a fix to let ppxlib not raise this error. So it was easier solved than I thought initially! I’ll release this today as graphql-ppx 1.1.1.
Finding a fix like this was exactly why I opened an issue, so not sure why the issue was closed on GitHub and not sure where the OCaml/JSOO comment comes from and why the discussion was locked. It was probably just misinterpreted by @Hongbo. I could probably have formulated the issue better.
I also created a PR to styled-ppx to solve this issue there.
Hi, let me explain why that issue is locked, I apologize that you are affected.
First, the topic itself is indeed something we won’t fix. Actually I made a post here two weeks ago Suggestions of naming conventions for third party ppx attributes . All third party attributes are encouraged to be qualified, the built-in attributes are not qualified, this is to allow us emit warnings for unused attributes. And I think it is repeated again and again, rescript is its own language.
Second, OSS is free service, we spend our time including weekends sharing something that we think is valuable, we ask for nothing but we want to be happy. Japp(the creator of the issue) is actively working on something which is hurting the ecosystem (he may think not) – it is perfectly fine, but I do think we have the option to decide how to spend our time. If he decides to contribute to our vision, he is welcome, if he is not, we wish him the best, but we just want to stay quiet and focus on our own tuff.
@Hongbo, can you be more elaborate on this? You think graphql-ppx is hurting the ecosystem? What is your proposed alternative?
I can’t imagine being productive with GraphQL without something like graphql-ppx.
I think you know what I mean. It’s okay to disagree & I wish you all the best.
For people who are reading the thread, it’s really not easy work to manage a community , I wish I could have your sympathy, we just want to stay quiet and focus on our own stuff
I honestly don’t know what you mean here. If you don’t want to say it publicly my DM’s are open.
I’ve always tried to be supportive. Sometimes I probably have had some feedback opposing some features given my experience as a user, when I thought that feedback might be valuable to the core-team, but I am fine if you discard it.
Hoooold. Let’s not accidentally misinterpret words here. Graphql is a fine use-case. Facebook created it after all.
There are several ways of implementing it. These technicalities, we can discuss better in various dedicated threads.
However, in general, ppx are discouraged, for both the aforementioned reasons and more. We do make a few exceptions here and there when the ROI is large, and graphql might count.
Completely agree. Ppx’s are not perfect indeed. Good to know rescript is still supportive when there is no better solution.
I just want reiterate, the issue had nothing to do with arguing for @deriving to be supported in the OCaml way, it was just an issue that some ppx’s that adopted ppxlib were breaking under the newest rescript release. So it seems like @Hongbo is still misunderstanding the issue.
We found a solution, but it would be better to have the discussion in the issue IMO and not lock it down entirely. This also has nothing to do with supporting the fork. ppxlib has been merged before there was a fork in some ppx’s, and it’s predecessor (ocaml-migrate-parsetree) was implemented to facilitate the parse tree migration from 4.02 to 4.06 some time ago and maintain backwards compatibility. And it also helps us support ReasonML native (but even if we wouldn’t support that, we still would need to use ppxlib).
Anyway this is the last thing I will say about it. I think it’s important to have have empathy, and assume good faith.
For people who need ppx in some cases, we recommend not relying on ppxlib.
ppxlib is introduced to solve the ABI instability in the native land, while it is not an issue in rescript, the parsetree is quite stable across releases.
We suffered from omp for quite a while due to the refmt parser which bloated the size significantly, it is better to not repeat the same mistake.
Ok this is interesting. Thanks for that. I didn’t know that as a ppx maintainer, and I am not aware of any ppx’s that do it this way currently. There are several issues with that from my standpoint:
bs-platform users were (you always have some transition period). This is happening again later this year.So going for this other approach will have some downsides aside from the extra work and not a big upside (some extra performance will be nice, but I don’t have the capacity to trade-off a lot of extra maintenance for performance because it’s all voluntary work).
The problem is solved for now so I think we are ok!
The whole story around ppx is quite demotivating. Some time ago, I finished transition of my ppx’es to ppxlib which was non-trivial and time consuming. Converting back ppx’es that heavily rely on extension points provided by ppxlib to anything else will be even more time consuming and I just don’t see myself going through this again tbh.
For people who are reading the thread, it’s really not easy work to manage a community
I’ve been around for awhile, I truly appreciate all the work that’s been done so far and I do as much as I can to push ReScript in the projects I’m involved in. But repetitive statements like this is a big red flag that indicates that communication is badly broken. From my point of view, this is the very first thing that needs to be fixed if having a healthy community is a priority.
We should probably fork this into a different thread. Ppx has always been an informally supported thing in ReScript and it’s time to document this a bit more clearly to avoid some expectation mismatches.
I know time is short and OSS is hard but at least a roadmap draft with a couple bullet points with the upcoming breaking changes or a forum post when they are released would be much appreciated.
We are all very supportive of ReScript but I just keep seeing lib authors being treated very harshly for no reason. It seems like ReScript is saying over and over that the previous ReasonML community and even the one that supported the transition is not welcome at all in this new paradigm shift. We’ll eventually listen.
Hey Gabriel, we’ve promoted these wherever we can:
Additionally there’s also been various private reach outs with people regarding breakages including this one, whenever doable.
More generally, we also maintained a roadmap on the compiler repo’s wiki and then shifted to announcing them on the forum for more eyes. Not to mention several standalone threads: 1 2 3 4, including various calls for testing.
This specific issue also wasn’t 100% a breakage from our side, considering we maintained that namespacing until now, and considering that we don’t have control over many of the technical architectures above which we’ve discouraged (but will discourage even more prominently). However you know discouragement isn’t enough; we have to provide a better alternative. Given your and others’ experience with ppx, you can imagine how long that takes. Seems like we need to re-prioritize this.
Paradigm shift means it’s not the same paradigm, and thus usually not same set of people either. Reason kept the native flavor and a more OCaml-oriented mindset. This has been described extensively in the rebranding blog post and whenever we get to yak shave a bit on the forum. See my comment history.
We were bound to lose some folks but even so, we did try keeping the old community intact. The most we’ve done was last week when after eight months, we archived the 3 rescript channels out of ~20 in Reason’s dedicated Discord (with an announcement, and without destroying existing message history); meanwhile the entire Reason forum has been left alone while I continue to pay the hosting cost out of my pocket.
I don’t wanna point finger but: the rebranding split was an agreed upon decision by all the leaders (not the community definitely, but at least the leaders). We’ve been managing our side. Where did the other side’s leader(s) go when we needed Reason-related engineering support during this transition? We had our engineering mishaps over this year, but it seems all the mishaps are handled by the ReScript side? And how come Patrick and I were the only ones cleaning up the Reason side of the docs? And why am I the only active admin on the Reason forum?
There might be a certain perception bias here.
Anyway, as the maintainer of the rescript-lang Twitter account, I’ve also seen and acknowledge your positive involvement in the ReScript community (as opposed to a lip service “we’re all very supportive of ReScript” said by a few recent folks with an entirely different agenda, so thank you for staying real). However, our recent surveys, private talks and forum stats also indicated to us that we’ve been going the right direction despite some flaws, where said flaws include vanishingly few “no announcement” over the last year. I’d like to suggest that it’s possible that you’ve repeatedly hit some pathological use-case along with a same group of people, which requires further diagnosis in a different thread.
@Hongbo @chenglou, your project is awesome. I love watching you all work. You all are not the greatest communicators but you can’t be good at everything and you certainly make the time when things get crazy. And with all the moving parts of developing a language, wow. Thanks for all you do. I genuinely look forward to see where you take us. I wish I new this compiler stuff enough to help you. Sorry you didnt get as much help as you could have used during the transition.
I can take over the discord server cost if you wanted to move on from it as it moves away from what you are doing.
Please do DM me.
I love all the positive stuff that is happening in the rescript ecosystem. And I am really thankful for that. I also agree that Reason has been in limbo a little with no clear leadership. In that area rescript clearly does a lot better at the moment.
We should respect the choices that the leaders like @chenglou are making. In most cases, it’s better to make a decision and rally behind that than no progress being made.
We should also be mindful that some people might be going through a rough patch, or have a bad day, and be decent ourselves. At least that’s what I am trying to do. This is a great community and let’s keep it this way!