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.
| @@ -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.
| "test:types": "tsc", | ||
| "test:format": "prettier --check .", | ||
| "fix:format": "prettier --write .", | ||
| "doc": "typedoc --out docs/typedoc src" |
There was a problem hiding this comment.
minor nit but I usually name this as build:docs
| "@types/node": "^18.19.54", | ||
| "eslint": "catalog:", | ||
| "prettier": "catalog:", | ||
| "typedoc": "^0.26.8", |
There was a problem hiding this comment.
I suggest moving these dependencies up to pnpm-workspace.yaml and marking them as catalog: dependencies; in general I think we should only be using numbered dependencies for places where some package needs to be held back from the rest of the monorepo for some reason.
| @@ -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.
| @@ -0,0 +1,9 @@ | |||
| { | |||
There was a problem hiding this comment.
Since you moved to swc, you no longer need this file.
| @@ -185,3 +186,5 @@ onlyBuiltDependencies: | |||
| - web3 | |||
| - web3-bzz | |||
| - web3-shh | |||
| ignoredBuiltDependencies: | |||
There was a problem hiding this comment.
You should add this to onlyBuiltDependencies, not ignoredBuiltDependencies. Adding it here will cause it to break in any environment where the binaries aren't already present.
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.