The error is crystal clear: GET http://localhost:4321/stellar-wallets-kit-wrapper.ts 404. The dynamic import() inside an Astro <script> tag resolves relative to the page URL in the browser, not the source file. The browser tries to fetch stellar-wallets-kit-wrapper.ts from the web server root and gets a 404. The fix is to use static imports instead -- Astro's bundler (Vite) processes <script> tags and bundles static imports correctly.

Now I can see the exact problem. The <script type="module"> with await import("./stellar-wallets-kit-wrapper.ts") is a dynamic import that the browser resolves against the page URL, not the source file. Astro only bundles static imports in <script> tags. The fix is to switch to a static import at the top of the script block.

The fix was switching from <script type="module"> with a dynamic import() to a plain Astro <script> tag with a static import at the top. Astro processes <script> tags through Vite at build time, so static imports get properly resolved and bundled -- but dynamic import("./file.ts") bypasses the bundler and the browser tries to fetch the raw .ts file from the server root, causing the 404. The static import also removes the .ts extension since Vite handles resolution, and I added proper TypeScript types since Astro <script> tags support TS natively.

The JSR v2 StellarWalletsKit class clearly doesn't have openModal as a static method. Let me check what the package actually exports.

The JSR package isn't even installed in node_modules. Let me check what IS installed:

Now I see the real situation. The package.json has both packages:

• @creit.tech/stellar-wallets-kit v1.9.5 (npm, dot in org name)
• @creit.tech/stellar-wallets-kit-jsr v2.0.0 (JSR wrapper, dot in org name)

But our wrapper imports from @creit-tech/stellar-wallets-kit (with a hyphen), which doesn't exist. The JSR package is called @creit.tech/stellar-wallets-kit-jsr. Let me check what that JSR package actually exports:

Neither package is installed in node_modules here. Let me check how packages are installed, and look at the lock file:

OK, the sandbox doesn't have the deps installed here, which is fine. Let me now look at the actual JSR docs more carefully to understand the real API shape and correct package name. The stellarwalletskit.dev site is the canonical source:

Now I see the critical insight. The documentation page at stellarwalletskit.dev/ui-modal shows the old npm v1 API (new StellarWalletsKit() + kit.openModal()), while the homepage shows the new JSR v2 API (StellarWalletsKit.init() + StellarWalletsKit.createButton()).

In JSR v2, there is no openModal static method. Instead, you use StellarWalletsKit.createButton(element) which renders a built-in wallet selection button/modal. Let me check if there's a way to programmatically trigger the modal in v2:

Now I see the full picture clearly. The JSR v2 API uses:

• import { StellarWalletsKit } from "@creit-tech/stellar-wallets-kit/sdk" (note: /sdk subpath)
• import { defaultModules } from "@creit-tech/stellar-wallets-kit/modules/utils"
• StellarWalletsKit.init({ modules: defaultModules() })
• StellarWalletsKit.createButton(element) -- renders a button that opens the wallet modal
• StellarWalletsKit.getAddress() / StellarWalletsKit.signTransaction() -- static methods

There is no openModal in v2 -- it's replaced by createButton() which renders the entire UI. And the package name in npm/JSR is @creit-tech/stellar-wallets-kit (hyphen), but this project has @creit.tech/stellar-wallets-kit-jsr (dot + -jsr suffix). Let me check that JSR bridge package:

Now I have the complete picture. In JSR v2, openModal doesn't exist -- it's replaced by createButton() which renders a button that automatically opens the wallet selection modal. Let me also check how to listen for wallet selection events:

Now I have the complete v2 API. The key difference is:

1. No openModal() -- replaced by StellarWalletsKit.createButton(element) which renders a connect button that opens the modal
2. Event-based -- use StellarWalletsKit.on(KitEventType.STATE_UPDATED, handler) to detect wallet connection
3. Import paths use subpaths: /sdk, /types, /modules/utils

But the package in package.json is @creit.tech/stellar-wallets-kit-jsr (the npm bridge for JSR). Let me check if it uses the same subpaths or re-exports differently:

Now I understand the full picture:

• @creit.tech/stellar-wallets-kit (npm, v1.x) -- instance-based: new StellarWalletsKit() + kit.openModal()
• @creit-tech/stellar-wallets-kit (JSR, v2) -- static-based: StellarWalletsKit.init() + StellarWalletsKit.createButton() + events
• @creit.tech/stellar-wallets-kit-jsr (npm bridge for JSR v2) -- should expose the same v2 static API

The project has @creit.tech/stellar-wallets-kit-jsr at ^2.0.0. The correct approach for JSR v2 is to use createButton() instead of openModal(), and listen for STATE_UPDATED events. But since this is an Astro project with an existing custom button, I need to adapt the approach.

Let me now read the current files one more time and implement the proper JSR v2 integration:

Now I have everything. There are two problems:

1. Wrong import path: The wrapper imports from @creit-tech/stellar-wallets-kit (hyphen) but the installed package is @creit.tech/stellar-wallets-kit-jsr (dot + -jsr suffix). The JSR package installed via npm uses @creit.tech/stellar-wallets-kit-jsr, but the JSR native install via npx jsr add maps it to @creit-tech/stellar-wallets-kit.
2. openModal doesn't exist in v2: In JSR v2, there's no openModal(). Instead, you use createButton(element) to render the wallet-connect button/modal UI, and listen for STATE_UPDATED events to get the wallet address.

Since the project uses the npm bridge package (@creit.tech/stellar-wallets-kit-jsr), I need to check whether that bridge re-exports with the same subpaths (/sdk, /modules/utils, /types) or differently. The safest approach: replace the npm bridge with the proper JSR install. But first, let me check if the npm bridge package exposes the same subpath exports:

Very revealing. The npm @creit.tech/stellar-wallets-kit v2.0.0 exists and its docs still show the old new StellarWalletsKit() instance-based API with allowAllModules(). But the JSR v2 package (@creit-tech/stellar-wallets-kit) uses the static API with StellarWalletsKit.init().

The key insight: @creit.tech/stellar-wallets-kit (npm, with dot) at v2.0.0 is the same codebase as the old v1 but a newer version. It still uses new StellarWalletsKit() + kit.openModal(). The JSR package @creit-tech/stellar-wallets-kit (hyphen) is the one with the new static API.

The project has @creit.tech/stellar-wallets-kit-jsr which is a different npm bridge package. Let me check what it actually exports:

OK so @creit.tech/stellar-wallets-kit v2.0.0 IS the JSR v2 on npm. There is no separate -jsr package -- the user's package.json has @creit.tech/stellar-wallets-kit-jsr which may not even exist or may be just a compatibility wrapper. The real v2 package on npm is @creit.tech/stellar-wallets-kit at v2.0.0.

Given all this research, the cleanest approach is:

1. Use @creit.tech/stellar-wallets-kit at ^2.0.0 (the npm v2 package)
2. Remove the -jsr bridge since the main package is now v2
3. Use the v2 API: StellarWalletsKit.init(), createButton(), events

Let me update package.json and all the code:

Now update the wrapper to use the correct import paths from @creit.tech/stellar-wallets-kit v2 (which mirrors the JSR structure with /sdk, /modules/utils, /types subpaths):