getcronit / pylon Goto Github PK

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?

Describe the bug
An unhandled exception causes the process to exit with code 1, requiring a manual restart of the pylon server.

To Reproduce
Steps to reproduce the behavior:

1. Go to src/index.ts
2. Explicitly throw an error

Expected behavior
The process should handle the exception gracefully and provide a clear error message without requiring a manual restart. Ideally, the development server should continue running, allowing the developer to fix the issue and retry without restarting the entire process.

Screenshots

Desktop:

• OS: MacOS Sonoma 14.5

Is your feature request related to a problem? Please describe.
I'm always frustrated when I can only use the requireAuth decorator inside classes. This limitation makes it difficult to implement authentication checks in functional programming paradigms or in cases where classes are not needed.

Describe the solution you'd like
I would like the requireAuth function to be usable directly, not just as a decorator. This would allow developers to wrap any function with requireAuth for authentication checks without the need to define a class. For example:

const test = requireAuth({}, () => {
  return "test";
});

Describe alternatives you've considered
An alternative could be to create a higher-order function that handles the authentication logic, but this requires additional boilerplate code and does not leverage the existing requireAuth logic.

Additional context
Currently, it is only possible to check for authentication when using the requireAuth decorator due to the nature of TypeScript decorators, which can only be used inside classes.

Example with the current implementation:

import { requireAuth } from "@getcronit/pylon";

class Test {
  @requireAuth()
  static test() {
    return "test";
  }
}

Desired implementation:

const test = requireAuth({}, () => {
  return "test";
});

This feature would streamline authentication checks and make the requireAuth function more versatile and user-friendly.

Is your feature request related to a problem? Please describe.

I'm always frustrated when the ServiceError class swallows the original error, making it impossible to build a complete stack trace. This behavior limits the ability to effectively debug and trace issues back to their origin.

Describe the solution you'd like

I suggest enhancing the ServiceError constructor to accept a third property called error, which will be assigned to this.cause. This change will preserve the original error and provide more context when handling errors.

Describe alternatives you've considered

An alternative solution could involve manually attaching the original error to the ServiceError instance in every catch block. However, this approach is cumbersome and error-prone compared to having built-in support within the ServiceError class itself.

Additional context

Here is a proposed change to the ServiceError class:

class ServiceError extends Error {
    constructor(message, code, error = null) {
        super(message);
        this.code = code;
        this.cause = error;
    }
}

Usage Example:

try {
    // Some operation that may throw an error
    throw new Error("Original error message");
} catch (err) {
    throw new ServiceError("Service failed", 500, err);
}

In this example, the original error is preserved within the ServiceError instance, allowing for better debugging and error handling.

Benefits:

• Improved debugging: Retains the original error, making it easier to identify the root cause.
• Enhanced error handling: Developers can access the original error details if needed.

The requirement for using Bun is a limitation as it can't be run on cloudflare workers or the like. Are there any plans to support any other runtimes? I am really eager to use this in my project however introducing Bun will add needless complexity to our architecture.

Thanks