[CPL-21044] dxt packaging
#12
Conversation
Necessary evil to make the dxt work with the built-in node in Claude Desktop
`better-sqlite3` relies on loading a native shared lib, which fails in Claude Desktop currently (`Claude 0.12.16 (fae442) 2025-07-14T19:10:28.000Z`) ``` dlopen(...) ... not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs ```
| if [ "$CURRENT_DIR" != "$REPO_ROOT" ]; then | ||
| echo "Error: This script must be run from the repository root" | ||
| echo "Current directory: $CURRENT_DIR" | ||
| echo "Repository root: $REPO_ROOT" | ||
| echo "Please cd to the repository root and run again" | ||
| exit 1 | ||
| fi |
There was a problem hiding this comment.
Just curious - why don't we cd there in the script instead?
There was a problem hiding this comment.
this would normally run it from the the repo root, but if not, we'd remind about it and not take implicit action
| { | ||
| "name": "get-data", | ||
| "description": "Get data from a Coupler.io data flow run." | ||
| }, | ||
| { | ||
| "name": "get-schema", | ||
| "description": "Get data table schema from a Coupler.io data flow." | ||
| }, | ||
| { | ||
| "name": "list-dataflows", | ||
| "description": "List my Coupler.io data flows." | ||
| }, | ||
| { | ||
| "name": "get-dataflow", | ||
| "description": "Get a Coupler.io data flow by ID." | ||
| } |
There was a problem hiding this comment.
So we'd have to update this list whenever we add new tools?
I'll try to make an automation which would update this using git hooks as I'm adding the new executions tool
There was a problem hiding this comment.
yes, the static list of tools is rendered in the extension page in their store, but I haven't seen descriptions there.
Most of our tools seem like a candidate for a shared npm package extraction – the implementation is the same in remote MCP with the exception of get-data/schema
| import { server } from '@/server' | ||
| import { logger } from '@/logger' |
There was a problem hiding this comment.
Hmm, instead of relative imports, wouldn't it work to simply import { server } from 'server' (absolute import).
Because in our tsconfig.json. I see we already have the "rootDir": "./src".
If that doesn't work, then maybe setting the compilerOptions.baseUrl attribute would do the trick (I see that's how we have it configured in the web repo)
Suggesting this only because relative imports could get out of hand quite quickly 😕
There was a problem hiding this comment.
this controls how Typescript resolves import paths and what paths it emits during compilation, but Node wouldn't know anything about it. Node would try to look for a module server in node_modules 🤷🏼♂️
(setting NODE_PATH has its own problems)
This has been an unsolved problem in Node for as long as I can remember. There's a bunch of workarounds and none of them work nicely/reliably compatible with all tools :) Subpath imports is one of them https://nodejs.org/api/packages.html#subpath-imports
Info on this change
Changes
dist/. Usetsxonly for devnode:sqliteto avoid loading shared native lib inbetter-sqlite3which currently fails in Claude DesktopNode dlopen faliure
How to test
.dxtfile in Claude Desktop and verify all existing flows