yes, same thing, I can add a support fn for it, can you open an issue for it?

sure

https://github.com/wilkerlucio/pathom3/issues/111

thanks

pco/final-value landed on main

k

did you alraedy have a function like this (just wrote this), and does it look ok, and do you want it in your lib if you don’t already have it?

(defn- p2-resolver? [r] (and (map? r) (contains? r :com.wsscode.pathom.connect/resolve)))
(defn- p2-mutation? [r] (and (map? r) (contains? r :com.wsscode.pathom.connect/mutate)))
(defn- p2? [r] (or (p2-resolver? r) (p2-mutation? r)))

(defn pathom2->pathom3
  "Converts a Pathom 2 resolver or mutation into one that will work with Pathom 3.

  Pathom 2 uses plain maps for these, and the following keys are recognized and supported:

  ::pc/sym -> ::pco/op-name
  ::pc/input -> ::pco/input as EQL
  ::pc/output -> ::pco/output
  ::pc/transform -> applied before conversion
  ::pc/mutate
  ::pc/resolve

  Returns the input unchanged of the given item is not a p2 artifact.

  NOTE: Any `transform` is applied at conversion time. Also, if your Pathom 2 resolver returns a value
  using Pathom 2 `final`, then that will not be converted into Pathom 3 by this function.

  You should manually convert that resolver by hand and use the new final support in Pathom 3.
   "
  [resolver-or-mutation]
  (if (p2? resolver-or-mutation)
    (let [{:com.wsscode.pathom.connect/keys [transform]} resolver-or-mutation
          {:com.wsscode.pathom.connect/keys [resolve sym input output mutate]} (cond-> resolver-or-mutation
                                                                                 transform (transform))
          config (cond-> {}
                   input (assoc ::pco/input (vec input))
                   output (assoc ::pco/output output))]
      (if resolve
        (pco/resolver sym config resolve)
        (pco/mutation sym config mutate)))
    resolver-or-mutation))

I dont have, I think this kind of code could live in a separate library, something like com.wsscode/pathom3-upgrade

it has no hard dep on p2, since it is just keywords

but if you’re also going to make compat stuff for plugins it could make sense.

yeah, just don't wanna mix upgrade related code in the main repo

k

nothing built-in for that

you don't need to, because the running process now is based on env, you can use it directly with p.eql/process

oh right…that makes sense

in pathom2 we can do a resolver that uses parser from env and works for both async and non-async process We can't do that in pathom3

@U2J4FRT2T what you mean? it should work on sync and async on Pathom 3 too, did you find something different?

(one difference is that you have to be aware which one it is on 3, so you can use the proper process fn, from p.eql or p.a.eql)

altough, you can know that, because Pathom fills that in the env when its async it puts ::p.a.eql/async-runner? true into it

Wait, this does solve some of the problems I'm having! WDYT about adding it somehow in the documentation? That's something I never though it would be useful 🙂