swift-node-unplugin

swiftNodeNativeAssets is an Unplugin integration for packages built with swift-node. It runs the project-local swift-node build command before bundling, then emits the generated target-qualified .node binaries and any Linux/Windows Swift runtime sidecars beside the bundled entry files.

tsdown

// tsdown.config.ts
import { defineConfig } from 'tsdown'
import swiftNodeNativeAssets from 'swift-node-unplugin/rolldown'

export default defineConfig({
  plugins: [swiftNodeNativeAssets()],
})

tsdown bundles the JavaScript runtime generated by Swift Node. The plugin leaves that code alone and emits files such as my_addon.darwin-arm64.node into the final output directory, where the runtime loads it at execution time. Linux and Windows retain target directories, so their Swift runtime sidecars stay beside the respective addon.

Pass build: false when another step already runs swift-node build:

swiftNodeNativeAssets({ build: false })

The plugin resolves and runs the project-installed swift-node package. It never uses npx.

Other bundlers

Use the adapter subpath that matches your bundler. Every adapter is a default factory following the normal Unplugin convention:

import swiftNodeNativeAssets from 'swift-node-unplugin/vite'
// or /rollup, /rolldown, /webpack, or /esbuild

export default {
  plugins: [swiftNodeNativeAssets()],
}

It is intended for Node-capable outputs such as libraries, servers, and Electron—not browser bundles. Vite SSR assets are retained automatically. esbuild requires outdir or outfile. If your bundle entry is nested (for example, server/index.js), pass assetDirectory: 'server' so the resolver and the emitted native sidecars stay together when using outdir. With outfile, sidecars are always placed beside that outfile; assetDirectory is therefore ignored.

On Windows, node.lib is a build-time import library, not a runtime asset. The plugin publishes the loadable .node addon and its Swift .dll sidecars; it never emits node.lib.

License

MIT