astrimid - Using tscircuit runframe as a librar...

rishabh and i will approve

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

okdok

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

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

🤷

this is stuff i barely remember tbh

all checks have passed

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

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

merged it

ok so the pipeline is now running

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

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

Ok. Now it works and automatically triggers. The next thing is `ky` and others, but let's see if the `debug` change fails anything

nice

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

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

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

this could be related

or are you saying it emerged earlier than your merge

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

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

lockfile issue

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

ye i think so

kind of interesting ci doesn't catch that

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

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

ye it should be part of the build test i think

that's also fine

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

only tsicruict.com and cli are triggered, so circuitjson.com needs manual update

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

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

perhaps runframe is too complicated

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

tsicruict.com has a large bump. Previous chore PR also failed https://github.com/tscircuit/tscircuit.com/pull/4122/changes

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

vercel deploy has been failing for a while on tscircuit.com I don't have access to logs: https://tscircuit-iujjb6e8y-tscircuit.vercel.app/

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

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

oof CC <@778624824875941908>

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

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

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

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

these repos copy core versions

that is legit a good system

so tscircuit/core generally informs the dep compatibility

they should copy core versions

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

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

they force merged?

it looks like the tests passed at the time

it seems a bit weird

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.

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

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

doesn't have anything suspicious

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

just link me to whatever you want to see

i'm clicking your links but confused where to go

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

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

on it

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

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

yea maybe core jsut needs to update

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

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",```

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

the problem is there's this massive circular dependency

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

https://tscircuit-7t4frzels-tscircuit.vercel.app/ https://github.com/tscircuit/tscircuit.com/pull/4125

could be too new `props`?

lol

wtf

maybe upgrading the node version would help?

i set it to 24

Ah, probably didn't update lock file properly

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

So updating props fixed the vercel issue

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

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

let's try upgrading 3d-viewer

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

Approved workflow Severin

everything succeeded

merging...

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.

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

merged

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" ```

A bit more stable, but still some random failures:

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.

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.