[Bug] An error occurs when applying TypeORM

[rhkdgns95]

Describe the bug An error occurs when importing Typeorm after installation. (But no error occurs in the case of import type {...} from "typeorm")

To Reproduce Steps to reproduce the behavior:

# typeorm install
bun add typeorm

# run
bun run develop

Expected behavior

Bundling Pylon: ./src/index.ts...
Bundling Pylon: done
17060 | // Save OS-specific path separator
17061 | var sep = path.sep;
17062 | 
17063 | // If we're in webpack, force it to use the original require() method
17064 | var requireFunction = ( true)
17065 |         ? eval("require")
               ^
ReferenceError: Can't find variable: require
      at 50658 

Screenshots

import TypeORM

package.json

Desktop (please complete the following information):

• OS: MAC
  • versions:
    • "@getcronit/pylon": "^1.1.1"
    • "@getcronit/pylon-builder": "^1.0.1"
    • "@getcronit/pylon-cli": "^1.0.0"
    • "@getcronit/pylon-server": "^1.0.0"

Additional context Hello.

I found out about this pylon while using Hono + TRPC.

This has the advantage of forming an API with a truly attractive concept. In the case of graphql, there were some disadvantages to creating a gql schema, but through hono + pylon, the graphql schema is automatically created through typescript and quick graphql construction is possible, which has the advantage, so I would like to apply it to the project as soon as possible.

Is there any way to solve this?

[schettn]

I will try to reproduce this quickly. I will let you know soon.

[schettn]

This is a known issue where some libraries cannot be bundled. For those packages Pylon offers an configuration option for external libraries.

Just add this to your apps/server/package.json:

"pylon": {
    "external": [
      "typeorm"
    ]
  },

Full example:

{
  "name": "my-pylon-project",
  "version": "0.0.1",
  "type": "module",
  "description": "Generated with `pylon new`",
  "files": [
    "package.json"
  ],
  "pylon": {
    "external": [
      "typeorm"
    ]
  },
  "dependencies": {
    "@getcronit/pylon": "*",
    "@getcronit/pylon-builder": "*",
    "@getcronit/pylon-server": "*",
    "bun-types": "^1.1.18",
    "typeorm": "^0.3.20"
  },
  "devDependencies": {
    "commitizen": "^4.2.5",
    "@getcronit/pylon-cli": "*"
  },
  "scripts": {
    "develop": "bun run pylon develop",
    "build": "bun run pylon build"
  }
}

[rhkdgns95]

@schettn

Thank you for quick response!

I'm looking to replace TRPC and build the graphql api via that pylon into production.

It won’t be a big problem if applied to operations, right?

Additionally, is there a way to directly modify the bundler settings set in the pylon package?

[schettn]

No, using external is completely fine. I am planning to improve the bundler in the future, but some libraries just don't like to be bundled into one file.

The idea behind this one file was to support deployment for e.g. Cloudflare runners where node_modules aren't supported (last time I checked).

[schettn]

Additionally, is there a way to directly modify the bundler settings set in the pylon package?

Currently not. Maybe after the mentioned bundler improvements. What are you thinking of / what would you like to modify?

[schettn]

I'm looking to replace TRPC and build the graphql api via that pylon into production.

My team and the team behind GQty are currently working on a collaboration that allows a tRPC like experience with end-to-end type safety between client and server.

https://github.com/user-attachments/assets/f8a67368-8d26-412c-bd72-1ef851af9b5c

[rhkdgns95]

@schettn

Currently not. Maybe after the mentioned bundler improvements. What are you thinking of / what would you like to modify?

It's not a big problem.

It seems that every time the code is modified, a build is run and a resulting file is created within the /.pylon/* directory.

I am curious about whether it is possible to control whether or not the file is source mapped or supported by some bundlers.

[rhkdgns95]

@schettn

My team and the team behind GQty are currently working on a collaboration that allows a tRPC like experience with end-to-end type safety between client and server.

Oh... that's what I want.

Are you creating an API type provider tool like trpc that does not require a code generate tool?

If I use the GQty library, is it possible to immediately use the code modified on the server on the front desk? (Is it possible to integrate with tanstack/react-query?)

[schettn]

GQty is not really a code generate tool but rather a GraphQL client that does not require writing GraphQL queries by building them on fly.

You can use const data = useQuery() inside you react component and access any data that the API offers. During the react lifecycle GQTy will automatically pick up what you need and write the query for you.

(Is it possible to integrate with tanstack/react-query?)

You cannot use this with react-query because you should not. GQTy handles everything you need.

[schettn]

If I use the GQty library, is it possible to immediately use the code modified on the server on the front desk?

When using GQTy right now you can use the --watch from GQTy (docs). But with the upcoming GQTy integration in Pylon, Pylon will handle the schema generation for you when you save you backend code. So yes, changes on the server will be immediately reflected to the client. Even the frontend data will update when you make changes to the backend.

Important: GQty's schema generation does not generate a full client but only pulls the GraphQL introspection. Afterwards the queries will be build on the fly depending on which data you access. So no over fetching. Take a look at the GQTy Readme

[rhkdgns95]

@schettn

Thank you for answer.

If the feature that applies real-time changes on the server side is updated in the future, it will be very useful in a monorepo environment.

Are there any ways to link middleware or libraries related to server settings? ex) hono logger, port change...

I can't change the port

[schettn]

You can change the port with bun develop --port 4000.

Are there any ways to link middleware or libraries related to server settings?

I will look into that and respond later.

Does the hono logger need server settings? I would integrate middleware it in the configureApp:

export const configureApp: PylonAPI['configureApp'] = app => {

  app.use(logger())
}

BTW: hono/logger is already integrated by default.

[rhkdgns95]

@schettn

BTW: hono/logger is already integrated by default.

You're right. For the logger, I tried customizing it as a winston logger.

Thank you for answer.

I would like to ask one last question.

It looks very surprising and attractive to configure the graphql server and configure the query request on the front end (via gqty) in a short time.

In the future, are you considering a feature that automatically creates providers such as useQuery, useMutation, cache... that combine gqty on the server? Currently, I want to check the data changes in useQuery in real time after modifying the backend code in the monorepo structure (like trpc).

It would be very useful to have a type provider that passes server changes through queries without using gqty's codegen command!

[schettn]

In the future, are you considering a feature that automatically creates providers such as useQuery, useMutation, cache... that combine gqty on the server?

Could you elaborate on this further? useQuery, useMutation.. are available through GQty on the client.

It would be very useful to have a type provider that passes server changes through queries without using gqty's codegen command!

Why without gqty's codegen? Currently you have to start the codegen yourself after server changes, but after my stated changes Pylon will call the qqty codegen for you. This only takes about a couple ms. Just like in the video I posted above.

[rhkdgns95]

@schettn

If I organize it again and give it to you,

If you modify a graphql query on the pylon server, it will be reflected immediately on the server.

Yes, no problem.

However, at the frontend, you need to execute the codgen command through gqty.

I asked if it was impossible not to use the codegen command.

If it was difficult, I wanted to maximize the advantages of the monrepo environment, which allows you to use the modified code right on the front page by executing the gqty codegen command at the same time as modifying graphql on the server.

[schettn]

But with the upcoming GQTy integration in Pylon, Pylon will handle the schema generation for you when you save you backend code.

Edit: Pylon will handle both. The server schema generation AND the client generation when you save your source code.

[rhkdgns95]

When a GraphQL query is modified, it appears to be reflected in real time on the client when applied as follows.

'/web' package.json

{
scripts: {
"codegen:watch": rm -rf src/_gqty && pnpx @gqty/cli http://localhost:4000/graphql --watch --target=src/_gqty/index.ts
}
}

'/server' package.json

{
scripts: {
"develop": "cp -p .env.copy.local .env && bun run pylon develop --port 4000",
}
}

[schettn]

I am closing this issue. In current beta Bun.build is used without the need to defined external.

Feel free to reach out if you need further help!