Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Remove createRemoteClient in arcjet and defer to adapters #46

Closed
Tracked by #928
blaine-arcjet opened this issue Nov 6, 2023 · 2 comments · Fixed by #932
Closed
Tracked by #928

Remove createRemoteClient in arcjet and defer to adapters #46

blaine-arcjet opened this issue Nov 6, 2023 · 2 comments · Fixed by #932
Assignees
@blaine-arcjet

Comments

@blaine-arcjet
Copy link
Contributor

These are internal details that help us or end-users with debugging, so I don't think these should be able to be changed via options. If that's our decision, we'll probably need to duplicate some code between arcjet and @arcjet/next for creating the RemoteClient since we won't be able to pass the SDK information as options.
@davidmytton
Copy link
Contributor

Agreed. They're for our usage only and shouldn't be configurable by end users.

@blaine-arcjet blaine-arcjet transferred this issue from another repository Dec 13, 2023
@blaine-arcjet
Copy link
Contributor Author

We need to remove createRemoteClient from the arcjet package since you can't export two functions with the same name. It probably needs to exist in the @arcjet/protocol package. We can then rename createNextRemoteClient (and the others in each adapter) to createRemoteClient and accept a different options object.

@blaine-arcjet blaine-arcjet changed the title Should sdkStack and/or sdkVersion be configurable by end users? Remove createRemoteClient in arcjet and defer to adapters Jun 11, 2024
This was referenced Jun 11, 2024
Open
Merged
@blaine-arcjet blaine-arcjet self-assigned this Jun 11, 2024
@trunk-io trunk-io bot closed this as completed in #932 Jun 12, 2024
trunk-io bot pushed a commit that referenced this issue Jun 12, 2024
@blaine-arcjet
chore!: Move client into protocol and rename builders in adapters (#932)
ea1c2b2 
Closes #46

This moves the `createClient` logic from the `arcjet` core package into the `@arcjet/protocol` package. It is then consumed by adapters, which all export a `createRemoteClient` function that fills in some of the required data. This ensures we don't try to double export these functions (via re-exports) while still allowing users to dive deep into `@arcjet/protocol/client.js` if they need it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@blaine-arcjet blaine-arcjet

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

chore!: Move client into protocol and rename builders in adapters arcjet/arcjet-js
2 participants
@davidmytton @blaine-arcjet