Cannot set basePath

[mikefrancis]

Hi there,

Using the docs I'm trying to set the .basePath() on the Hono instance and it doesn't appear to be working.

Any tips?

Many thanks

[schettn]

Hi @mxkxf, sorry I have overlooked this issue. Is it still relevant?

[mikefrancis]

No problem @schettn, it is still an issue yes.

Full transparency, we're actually looking at migrating to graphql-server middleware as we're finding TDD a little difficult with Pylon and any issues like this one are also pushing us towards graphql-server.

[schettn]

Regarding the base path issue – Pylon uses an internal app instance with some preconfiguration where it sets the GraphQL handler. All userland routes are applied to said instance. While you can add your own Hono instance with app.route("path", new Hono()...), you cannot change the basePath with app.basePath because that would mean you have to replace the internal app.

To fix this, I will implement a new config option to set the basePath. This will then apply to all routes, including the GraphQL endpoint.

import { app, PylonConfig } from '@getcronit/pylon'

export const graphql = {
  Query: {
    hello: () => "World"
  },
  Mutation: {}
}

export const config: PylonConfig = {
  basePath: "/foo"
}

export default app

---

Totally understand your thoughts on TDD with Pylon – I am actively trying to improve the DX and testability, so if you have any specific feedback, I would love to hear it (and potentially address it before you fully migrate). Either way, happy to support however I can.

---

Looking ahead, Pylon aims to be a framework for full-stack/backend GraphQL development with features like breaking change detection, automatic date-based versioning, and more that will make building applications a breeze.

Pylon V3 will bring many improvements to the plug-in system, including a more general authentication plug-in that is not exclusively tied to ZITADEL, and most importantly, a new Pages plug-in that brings full-stack development with React (reference).

[schettn]

Hi there,

Using the docs I'm trying to set the .basePath() on the Hono instance and it doesn't appear to be working.

Any tips?

Many thanks

The underlying issue is that app.basePath('/api') returns a new Hono instance. This means you can do the following:

import { app as pylonApp } from '@getcronit/pylon' 

const app = pylonApp.basePath("/api")

app.get("/foo")

export default app

Now your endpoints are all prefixed with /api. The /graphql route will not be prefixed with the basePath because in V2 the graphql handler is added BEFORE the user land code (including pylonApp.basePath("/api"). This will change in V3.

Thus, you have to change the graphqlEndpoint in the config additionally (this is possible although not typed yet).

Final code:

import { app as pylonApp, PylonConfig } from '@getcronit/pylon' 

const app = pylonApp.basePath("/api")

app.get("/foo")

export const config: PylonConfig = {
  graphqlEndpoint: "/api/graphql"
}

export default app

[mikefrancis]

That would be great, do you know roughly when V3 is due for release?

On the TDD DX, any way of being able to be able to not need to rebuild Pylon whenever the source changes for Node (I know this isn't the case for Bun) would be fantastic.

Interesting that you mentioned this:

Looking ahead, Pylon aims to be a framework for full-stack/backend GraphQL development with features like breaking change detection, automatic date-based versioning, and more that will make building applications a breeze.

Our rationale for using Pylon was it seemed to be a batteries included middleware + schema generation for Hono. We are probably in the minority here, but the full-stack features are not appealing to us as we use this entirely on the back-end.

[schettn]

@mxkxf

That would be great, do you know roughly when V3 is due for release?

Probably in the upcoming weeks. Most features are done, some testing and improving the build performance are still ongoing.

On the TDD DX, any way of being able to be able to not need to rebuild Pylon whenever the source changes for Node (I know this isn't the case for Bun) would be fantastic.

I will create an issue for that and work something out after some research

Our rationale for using Pylon was it seemed to be a batteries included middleware + schema generation for Hono. We are probably in the minority here, but the full-stack features are not appealing to us as we use this entirely on the back-end.

Modules like Full-Stack will be opt-in via a plugin system which you can manually configure or choose as a feature during npm create pylon. So pylon without plugins will always be about backend development with graphql.