# astrimid - Using tscircuit runframe as a librar...

Channel: #support
Source: https://discord.com/channels/1233487248129921135/1531639565788647506
Started: 2026-07-28T12:28:49.489000+00:00
Last activity: 2026-07-29T09:42:25.277000+00:00

## Seve — 2026-07-28T23:44:29.675000+00:00

maybe do a README change or something minor so that you become a trusted contrib

## Seve — 2026-07-28T23:44:33.420000+00:00

rishabh and i will approve

## astrimid — 2026-07-28T23:46:01.423000+00:00

could you retrigger one last time and I'll try that Readme change.

Should show us whether it's network access or some problem with bun/npmrc
Attachment: image.png — https://community.tscircuit.com/media/1531809990514577558

## Seve — 2026-07-28T23:46:10.125000+00:00

okdok

## astrimid — 2026-07-28T23:48:52.223000+00:00

Should be straightforward change in line with moving `devDepdendencies` to `dependencies`:
https://github.com/tscircuit/runframe/pull/4200

## astrimid — 2026-07-28T23:50:11.640000+00:00

unless tscircuit.com injects a different `debug` package or something?

## Seve — 2026-07-28T23:50:18.862000+00:00

🤷

## Seve — 2026-07-28T23:50:26.820000+00:00

this is stuff i barely remember tbh

## astrimid — 2026-07-28T23:50:49.743000+00:00

all checks have passed

## astrimid — 2026-07-28T23:52:17.782000+00:00

should I prepare a revert PR in case it breaks anything?

## astrimid — 2026-07-28T23:53:58.593000+00:00

preview seems to work, so doesn't break runframe itself

## Seve — 2026-07-28T23:54:09.253000+00:00

merged it

## Seve — 2026-07-28T23:54:27.671000+00:00

ok so the pipeline is now running

## Seve — 2026-07-28T23:54:46.539000+00:00

https://release-tracker.tscircuit.com/

## Seve — 2026-07-29T00:00:20.371000+00:00

it triggers to tscircuit.com, circuitjson.com and tscircuit/cli https://docs.tscircuit.com/contributing/package-dependencies-and-auto-updates

## astrimid — 2026-07-29T00:00:22.626000+00:00

Ok. Now it works and automatically triggers.
The next thing is `ky` and others, but let's see if the `debug` change fails anything
Attachment: image.png — https://community.tscircuit.com/media/1531813602342994001

## Seve — 2026-07-29T00:00:40.956000+00:00

nice

## astrimid — 2026-07-29T00:18:47.416000+00:00

tscircuit.com PR failed 4 hours ago, so not me:
https://github.com/tscircuit/tscircuit.com/pull/4122

## astrimid — 2026-07-29T00:22:19.868000+00:00

circuitjson.com appears to be updated manually? https://github.com/tscircuit/circuitjson.com/pulls

## astrimid — 2026-07-29T00:24:00.613000+00:00

Bot didn't run on cli yet:
https://github.com/tscircuit/cli/pulls

## Seve — 2026-07-29T00:24:18.737000+00:00

[attachment]
Attachment: image.png — https://community.tscircuit.com/media/1531819626038562826

## Seve — 2026-07-29T00:24:23.800000+00:00

this could be related

## Seve — 2026-07-29T00:24:42.108000+00:00

or are you saying it emerged earlier than your merge

## astrimid — 2026-07-29T00:25:30.346000+00:00

The bot didn't bump runframe yet: https://github.com/tscircuit/runframe/blob/main/package.json
So it's not released to npm yet?

## Seve — 2026-07-29T00:25:51.303000+00:00

https://github.com/tscircuit/runframe/actions/runs/30409454026/job/90442122819

## Seve — 2026-07-29T00:25:53.220000+00:00

lockfile issue

## astrimid — 2026-07-29T00:27:18.694000+00:00

ah, my fault, so should I run bun install locally and submit lockfile as a new PR?

## Seve — 2026-07-29T00:27:33.665000+00:00

ye i think so

## Seve — 2026-07-29T00:27:38.257000+00:00

kind of interesting ci doesn't catch that

## astrimid — 2026-07-29T00:28:12.348000+00:00

yeah, very strange only publish has --frozen-lockfile, not individual prs

## astrimid — 2026-07-29T00:41:08.123000+00:00

Done: https://github.com/tscircuit/runframe/pull/4201/changes
Added --frozen-lockfile to PR workflow as well

## Seve — 2026-07-29T00:41:10.663000+00:00

ye it should be part of the build test i think

## Seve — 2026-07-29T00:41:19.412000+00:00

that's also fine

## Seve — 2026-07-29T00:41:43.345000+00:00

yea and you can see you're a trusted contrib now

## astrimid — 2026-07-29T00:44:46.050000+00:00

only tsicruict.com and cli are triggered, so circuitjson.com needs manual update
Attachment: image.png — https://community.tscircuit.com/media/1531824773657788628

## Seve — 2026-07-29T00:46:00.302000+00:00

i think circuitjson.com might have the dep but it might also pull the latest version automatically?

## Seve — 2026-07-29T00:46:07.324000+00:00

if not we should have it be a dynamic import if possible

## Seve — 2026-07-29T00:46:11.819000+00:00

perhaps runframe is too complicated

## Seve — 2026-07-29T00:46:23.887000+00:00

or somebody failed to tscircuit/plop the automatic update receiving workflow

## astrimid — 2026-07-29T00:47:47.244000+00:00

tsicruict.com has a large bump. Previous chore PR also failed
https://github.com/tscircuit/tscircuit.com/pull/4122/changes
Attachment: image.png — https://community.tscircuit.com/media/1531825534349213747

## astrimid — 2026-07-29T00:49:03.803000+00:00

cli succeeded and merged:
https://github.com/tscircuit/cli/pull/3903

## astrimid — 2026-07-29T00:52:04.709000+00:00

vercel deploy has been failing for a while on tscircuit.com

I don't have access to logs:
https://tscircuit-iujjb6e8y-tscircuit.vercel.app/

## astrimid — 2026-07-29T00:55:49.005000+00:00

First failure or runframe update after last success:
https://github.com/tscircuit/tscircuit.com/pull/4058/changes
First failure of eval update after last success:
https://github.com/tscircuit/tscircuit.com/pull/4098/changes

## astrimid — 2026-07-29T01:02:13.117000+00:00

These two releases failed vercel deploy:
 "@tscircuit/runframe": "^0.0.2272",
"@tscircuit/3d-viewer": "^0.0.578",
"@tscircuit/eval": "^0.0.1075",

I tracked down runframe change:
https://github.com/tscircuit/runframe/pull/4090/changes#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519R71

## Seve — 2026-07-29T01:03:36.030000+00:00

oof CC <@778624824875941908>

## astrimid — 2026-07-29T01:03:41.621000+00:00

`"circuit-json": "^0.0.454",` is added to `runframe` devDepdencies.
But the tsircuit.com is not updated

## Seve — 2026-07-29T01:03:46.388000+00:00

he's going to be offline for a while- is there an easy fix here

## astrimid — 2026-07-29T01:03:55.607000+00:00

That's the exactly kind of issue I'm complaining about

## Seve — 2026-07-29T01:04:29.915000+00:00

not sure exactly what you're saying, are you saying it shouldn't be a dev dep

## Seve — 2026-07-29T01:04:32.636000+00:00

these repos copy core versions

## Seve — 2026-07-29T01:04:36.580000+00:00

that is legit a good system

## Seve — 2026-07-29T01:04:47.474000+00:00

so tscircuit/core generally informs the dep compatibility

## Seve — 2026-07-29T01:04:52.504000+00:00

they should copy core versions

## astrimid — 2026-07-29T01:07:40.860000+00:00

The only thing I know for sure is that `"circuit-json": "^0.0.454"` is a runtime dependency of `runframe` that broke vercel build and prevented future tscircuit.com deploys to vercel preview. Then, PR #4097 was force merged despite failing vercel preview: https://github.com/tscircuit/tscircuit.com/pull/4097

## astrimid — 2026-07-29T01:07:55.836000+00:00

I don't know how tscircuit.com still works, maybe running an older version

## Seve — 2026-07-29T01:08:42.157000+00:00

they force merged?

## Seve — 2026-07-29T01:08:49.454000+00:00

it looks like the tests passed at the time

## Seve — 2026-07-29T01:09:17.937000+00:00

it seems a bit weird

## astrimid — 2026-07-29T01:45:26.004000+00:00

Ok, I might have misread. First deploy failed, then some change then succeded. The change was this:
```
"circuit-to-svg": "^0.0.376",
    "circuit-to-svg": "^0.0.393",
```


autoupdater bumped runframe:

```
"@tscircuit/runframe": "^0.0.2291",
```
and 3d viewer:

`"@tscircuit/3d-viewer": "^0.0.578",`

that failed, so <@1238122660345548882>   bumped manually, but skipped 3d-viewer: 

`"@tscircuit/runframe": "^0.0.2291",`

That still failed, then he added this:
```
- "circuit-to-svg": "^0.0.376",
+ "circuit-to-svg": "^0.0.393",
```

This succeded, but subsequent bumps still want to update that 3d-viewer. So might be not caused by runframe. I stil believe `circuit-json` should be a runtime dependency of runframe, not devDependency.

Might try that next and look into 3d-viewer bump.
Attachment: image.png — https://community.tscircuit.com/media/1531840040760770591

## astrimid — 2026-07-29T01:47:09.043000+00:00

This is the first PR that failed after the successful merge:
https://github.com/tscircuit/tscircuit.com/pull/4098/changes

## astrimid — 2026-07-29T01:48:30.433000+00:00

Last release of 3d-viewer was also 4 days ago:
https://github.com/tscircuit/3d-viewer/pull/958

## astrimid — 2026-07-29T01:49:11.282000+00:00

doesn't have anything suspicious

## astrimid — 2026-07-29T01:49:37.274000+00:00

could it be just vercel infrastructure issue? anyone could peek into that vercel logs?

## Seve — 2026-07-29T01:50:08.057000+00:00

just link me to whatever you want to see

## Seve — 2026-07-29T01:50:34.152000+00:00

i'm clicking your links but confused where to go

## Seve — 2026-07-29T01:50:50.179000+00:00

juggling a few threads at the moment, we're currently fabricating 🔨

## astrimid — 2026-07-29T01:52:59.010000+00:00

https://tscircuit-n89ks9407-tscircuit.vercel.app/ viewbuild button?

## Seve — 2026-07-29T01:53:26.721000+00:00

on it

## Seve — 2026-07-29T01:53:49.747000+00:00

[attachment]
Attachment: image.png — https://community.tscircuit.com/media/1531842153687289916

## astrimid — 2026-07-29T01:56:47.591000+00:00

So `bun add @tscircuit/props@latest` should work?

## astrimid — 2026-07-29T01:57:45.559000+00:00

`core` is trying to use `busProps` property from `props`

## Seve — 2026-07-29T01:57:45.562000+00:00

yea maybe core jsut needs to update

## Seve — 2026-07-29T01:58:05.469000+00:00

busProps are somewhat new, `npm ls @tscircuit/props` may reveal why that dep is getting duped

## astrimid — 2026-07-29T02:00:06.167000+00:00

same issue essentially, `core` has new `props` in `devDependencies`. `tscircuit.com` depdends on `core` but doesn't inherit its new dependency. The autoupdater bot for some reason doesn't bump the `props` version in `tsicrcuit.com`:

```
"@tscircuit/props": "^0.0.567",```

## Seve — 2026-07-29T02:00:36.963000+00:00

we could set up the same script that a bunch of repos have to copy the same versions that core has 🤔

## Seve — 2026-07-29T02:00:48.685000+00:00

the problem is there's this massive circular dependency

## astrimid — 2026-07-29T02:01:34.847000+00:00

let's try to bring new `props` package to `.com` first

## astrimid — 2026-07-29T02:08:51.318000+00:00

https://tscircuit-7t4frzels-tscircuit.vercel.app/

https://github.com/tscircuit/tscircuit.com/pull/4125

## astrimid — 2026-07-29T02:09:13.605000+00:00

could be too new `props`?

## Seve — 2026-07-29T02:11:47.126000+00:00

lol
Attachment: image.png — https://community.tscircuit.com/media/1531846672815095818

## Seve — 2026-07-29T02:11:48.046000+00:00

wtf

## Seve — 2026-07-29T02:12:08.568000+00:00

maybe upgrading the node version would help?

## Seve — 2026-07-29T02:13:50.426000+00:00

i set it to 24

## astrimid — 2026-07-29T02:14:50.468000+00:00

Ah, probably didn't update lock file properly

## astrimid — 2026-07-29T02:32:04.193000+00:00

busrouting was added 2 days ago:
https://github.com/tscircuit/props/pull/758

## astrimid — 2026-07-29T02:32:21.338000+00:00

So updating props fixed the vercel issue

## astrimid — 2026-07-29T02:33:24.609000+00:00

or did it. need to merge to find out:
https://github.com/tscircuit/tscircuit.com/pull/4125/changes
props could be not the only issue

## astrimid — 2026-07-29T02:34:10.418000+00:00

first 3d-viewer failure was 4 days ago, so props is a compounding issue

## astrimid — 2026-07-29T02:42:42.770000+00:00

let's try upgrading 3d-viewer

## astrimid — 2026-07-29T02:47:34.144000+00:00

that didn't fail either. so the `props` change might be the single culprit for all tsicruit.com failures for the last 4 days.

## Seve — 2026-07-29T02:47:44.994000+00:00

Approved workflow Severin

## astrimid — 2026-07-29T02:48:36.009000+00:00

everything succeeded

## Seve — 2026-07-29T02:48:49.195000+00:00

merging...

## astrimid — 2026-07-29T02:51:21.180000+00:00

it's still would be running everything prior to my `debug` change, so any failures here, would be because of previous changes, as runframe isn't updated yet.

## astrimid — 2026-07-29T03:11:10.233000+00:00

Run frame upgrade PR ready to merge whenever: https://github.com/tscircuit/tscircuit.com/pull/4127

## Seve — 2026-07-29T03:11:33.498000+00:00

merged

## astrimid — 2026-07-29T04:51:36.903000+00:00

https://github.com/tscircuit/runframe/pull/4205
Bun library consumption passes with dependencies moved. There are some warnings:
```
warn: incorrect peer dependency "@emnapi/core@1.11.1"

warn: incorrect peer dependency "@emnapi/runtime@1.11.1"

@types/node@24.13.3 (v26.1.2 available)

typescript@6.0.3 (v7.0.2 available)

npm warn   peer react@"19.1.0" from @tscircuit/3d-viewer@0.0.578

npm warn peer react@"^16.8.0 || ^17.0.0 || ^18.0.0" from react-query@3.39.3

npm warn Conflicting peer dependency: react@18.3.1

circuit-json@"^0.0.453" from tscircuit@0.0.2142

peer circuit-json@"^0.0.446" from @tscircuit/cli@0.1.1769

 deprecated prebuild-install@7.1.3: No longer maintained.

deprecated glob@7.2.3: Old versions of glob are not supported, and contain widely publicized security vulnerabilities, which have been fixed in the current version.

deprecated rimraf@3.0.2: Rimraf versions prior to v4 are no longer supported

26 vulnerabilities (6 moderate, 20 high)

warn: incorrect peer dependency "typescript@6.0.3"

warn: incorrect peer dependency "react@19.2.8"

warn: incorrect peer dependency "circuit-json@0.0.454"

warn: incorrect peer dependency "@tscircuit/alphabet@0.0.25"
```

## astrimid — 2026-07-29T09:33:12.128000+00:00

A bit more stable, but still some random failures:
Attachment: image.png — https://community.tscircuit.com/media/1531957758134587545

## astrimid — 2026-07-29T09:38:29.690000+00:00

Hm, not failures actually, just bot closing unmerged PRs because of rapid fire of updates. And one sorta race condition bug: when bot triggers update from runframe for example, it closes the PR triggered by another bump requrest, like eval. So now eval isn't up to date because runframe triggered change closed that PR. So now eval is out of sync.

## astrimid — 2026-07-29T09:42:25.277000+00:00

Completely separate issue from this thread, but if eval and runframe are changed to use `"^1.0.1088"` for example, the upgrade script would only have to do bun.lock update which would bump both evan and runframe.

As a short term fix, bot shouldn't close PRs not created by the job.