feat(lazer): create js solana sdk package #2899
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Riateche
force-pushed
the
publish-lazer-solana-js-package2
branch
from
8437764 to
a0cb877
Compare
| @@ -0,0 +1,6 @@ | |||
| import type { PythLazerSolanaContract } from "./idl/pyth-lazer-solana-contract.js"; | |||
There was a problem hiding this comment.
was the .js in the end necessary :?
There was a problem hiding this comment.
This is needed when using nodenext module resolution, in which typescript does not transform import paths at all. See https://www.typescriptlang.org/docs/handbook/modules/theory.html#module-resolution for reference.
In general, nodenext is the preferred module resolution for anything that supports node (and IMO, any published lib should be using it as it's the most future-proof option). The short explanation is that nodenext leaves imports alone when transpiling, meaning the import path gets passed directly to node. Since node requires extensions when using esm, so then does the nodenext module resolution strategy (this also explains why the extension is .js and not .ts).
For more context, eventually node will change so that type annotations are just ignored at runtime, and at that point typescript will no longer be a transpiler and just a type checker, similar to mypy in python.
lazer/contracts/solana/package.json
Outdated
| @@ -6,6 +6,7 @@ | |||
| "fix:format": "prettier --write **/*.*", | |||
| "test:format": "prettier --check **/*.*", | |||
| "test:anchor": "CARGO_TARGET_DIR=\"$PWD/target\" RUSTUP_TOOLCHAIN=nightly-2025-04-15 anchor test", | |||
| "update-idl": "RUSTUP_TOOLCHAIN=nightly-2025-04-15 anchor build && cp target/types/pyth_lazer_solana_contract.ts ../../sdk/js-solana/src/idl/pyth-lazer-solana-contract.ts && cp target/idl/pyth_lazer_solana_contract.json ../../sdk/js-solana/src/idl/pyth-lazer-solana-contract.json", | |||
There was a problem hiding this comment.
I don't personally like having a task in one package which reaches into and updates another package. Personally, I'd put this as a build:idl sub-task on the @pythnetwork/pyth-lazer-solana-sdk package instead, given it's a task that builds files for that package.
If you really want to be pedantic, you leave something like RUSTUP_TOOLCHAIN=nightly-2025-04-15 anchor build here, and then add the cp commands in @pythnetwork/pyth-lazer-solana-sdk, and set up turbo so the latter depends on the former.
There was a problem hiding this comment.
I moved the update-idl task to the @pythnetwork/pyth-lazer-solana-sdk package. I agree that generating IDL as part of the build process would be a cleaner way to do this, but I don't want to introduce anchor as a build dependency to JS packages. We tried to do that before with the Lazer Solana contract tests, and it was constantly causing problems for people.
| @@ -0,0 +1,464 @@ | |||
| { | |||
There was a problem hiding this comment.
If these files are generated, I suggest not checking them in. Instead, ensure the build tasks are correctly ordered so the files get generated as part of building this package. I personally really prefer not to check these files in, since it is effectively a cache and checking them in means you are now susceptible to cache sync issues.
| @@ -0,0 +1,6 @@ | |||
| import type { PythLazerSolanaContract } from "./idl/pyth-lazer-solana-contract.js"; | |||
There was a problem hiding this comment.
This is needed when using nodenext module resolution, in which typescript does not transform import paths at all. See https://www.typescriptlang.org/docs/handbook/modules/theory.html#module-resolution for reference.
In general, nodenext is the preferred module resolution for anything that supports node (and IMO, any published lib should be using it as it's the most future-proof option). The short explanation is that nodenext leaves imports alone when transpiling, meaning the import path gets passed directly to node. Since node requires extensions when using esm, so then does the nodenext module resolution strategy (this also explains why the extension is .js and not .ts).
For more context, eventually node will change so that type annotations are just ignored at runtime, and at that point typescript will no longer be a transpiler and just a type checker, similar to mypy in python.
Riateche
force-pushed
the
publish-lazer-solana-js-package2
branch
from
a0cb877 to
5db6ec3
Compare
Summary
Create a JS package for interacting with Lazer Solana on-chain contract. The package includes:
I will also add an example for working with it to the
pyth-examplesrepo.Rationale
We removed signature helper from our main JS SDK because we don't want it to depend on Solana packages.
How has this been tested?
Locally built the package and used it as a dependency in examples.