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.

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

Error when Using Arktype Resolver #1022

Open
lucaschultz opened this issue Jun 19, 2024 · 4 comments
Open

Error when Using Arktype Resolver #1022

lucaschultz opened this issue Jun 19, 2024 · 4 comments
Assignees
Labels
bug Something isn't working

Comments

@lucaschultz
Copy link

Report a bug

This is a duplicate of issue #693 in the @hookform/resolvers repository. Basically, I tried using the arktypeResolver in the context of a Next.js and Vite/React app, both times with the same result:

🔎 Search Terms

  • resolvers
  • hook form

🧩 Context

  • ArkType version: 2.0.0-dev.24
  • TypeScript version (5.1+): 5.2.2
  • Other context you think may be relevant (JS flavor, OS, etc.): Used with @hookform/resolvers@3.6.0 and react-hook-form@7.52.0

🧑‍💻 Repro

I created a (almost) minimal reproduction here.

@lucaschultz lucaschultz added the bug Something isn't working label Jun 19, 2024
@ssalbdivad
Copy link
Member

As of now we only support ESM in 2.0. I'm surprised to see you're getting this error though and not something complaining about an import.

I will try to take a deeper look at this in the next few days so we can at least get the bottom of how you're getting that error as I want to make sure we're not somehow getting two versions of the package e.g. from the peer dep in react-hook-form.

@ssalbdivad
Copy link
Member

I did take a quick look at @hookform/resolvers and noticed the following their package.json:

    "./arktype": {
      "types": "./arktype/dist/index.d.ts",
      "umd": "./arktype/dist/arktype.umd.js",
      "import": "./arktype/dist/arktype.mjs",
      "require": "./arktype/dist/arktype.js"
    },

Given ArkType 2.0 doesn't currently support CJS, I wonder if this could cause problems or if there's at least a better way to avoid a confusing error like this.

ArkType currently publishes the following in its package.json:

	"type": "module",
	"main": "./out/index.js",
	"types": "./out/index.d.ts",
	"exports": {
		".": "./out/index.js",
		"./config": "./out/config.js",
		"./internal/*": "./out/*"
	},
	

Would it be perhaps better if I specified import specifically and no require condition to try and get that resolution to fail transparently? Is there anything we could change in @hookform/resolvers to improve this?

CC @Andarist since I helplessly defer to him whenever I have questions about this sort of thing 😆

@kevinwcyu
Copy link

Hi, I have a reproduction of the same error https://github.com/kevinwcyu/arktype-nextjs-registry-error. I created an app with npx create-next-app@latest. I created a type with arktype in app/form.ts and imported that type in app/page.tsx.

You can reproduce it by

  1. run npm install
  2. run npm dev
  3. open http://localhost:3000/
  4. refresh the page and it should show an error Error: Tried to initialize an $ark registry but one already existed.

Note: This doesn't happen if you run npm run build && npm start (building a production version and running it). This appears to only happen in dev mode. I found this issue in the Next.js repo about modules being evaluated multiple times. Some comments in that issue mention modules being evaluated multiple times in dev mode so that might be a clue with what's happening here as well. @lucaschultz, from the Vite/React app that you're working on, do you see the error only in development or when you build and run it as well?

I'm using the following:
ArkType version: 2.0.0-dev.26
TypeScript version (5.1+): 5.5.2

@Andarist
Copy link
Contributor

Would it be perhaps better if I specified import specifically and no require condition to try and get that resolution to fail transparently? Is there anything we could change in @hookform/resolvers to improve this?

As mentioned in DMs, I don't think this would change a thing here.

If Arktype doesn't offer CJS then @hookform/resolvers likely shouldn't offer @hookform/resolvers/arktype for CJS consumers. They could use "require": null there to make it more apparent. But since they also use types condition first they would have to restructure that manifest only to provide types for import

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: Backlog
Development

No branches or pull requests

4 participants