# anil - tscircuit/core doesn't update in tscircu...

Channel: #contributor
Source: https://discord.com/channels/1233487248129921135/1531826748495368193
Started: 2026-07-29T00:52:37.488000+00:00
Last activity: 2026-07-29T21:27:06.218000+00:00

## anil — 2026-07-29T00:52:36.806000+00:00

tscircuit/core doesn't update in tscircuit/eval.
Attachment: image.png — https://community.tscircuit.com/media/1531826748248031242

## techmannih — 2026-07-29T00:53:40.535000+00:00

Yes we are looking into same

## techmannih — 2026-07-29T00:54:29.563000+00:00

Seems like fanout-solver dep issue in core

## techmannih — 2026-07-29T00:54:37.565000+00:00

Can you fix it?

## Seve — 2026-07-29T01:05:19.703000+00:00

is it using github style installtion

## Krishna — 2026-07-29T01:05:41.094000+00:00

yeah i taught why format-si-unit is not auto-updated, then i done by myself by updating to core and it started throwing failled buntest .

## Seve — 2026-07-29T01:05:45.480000+00:00

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

## Seve — 2026-07-29T01:05:46.052000+00:00

yea

## techmannih — 2026-07-29T01:05:52.386000+00:00

Yes

## Seve — 2026-07-29T01:06:02.296000+00:00

we can only use that in the autorouter

## Seve — 2026-07-29T01:06:13.857000+00:00

(or anything that gets bundled before release- core doesn't get bundled)

## Seve — 2026-07-29T01:06:59.577000+00:00

CC <@1525187702029549659> another random dep issue, just adding some complexity 😉

## astrimid — 2026-07-29T01:13:35.240000+00:00

could be a bug in bun, issue with github networking or some permission issue with github actions. maybe even that git revision is unavailable for some reason. `resolve` hints a DNS issue

## Seve — 2026-07-29T01:19:16.825000+00:00

i think whenever a repo isn't bundled we have to avoid using github deps

## Seve — 2026-07-29T01:19:23.923000+00:00

the autorouter is bundled so can use github deps

## astrimid — 2026-07-29T01:21:33.157000+00:00

suggested fix range is changing DNS in the workflow image:
```
container:
  image: node:20 # or whatever
  options: --dns 1.1.1.1 --dns 8.8.8.8
```

As both npm and github are owned by microsoft and probably hosted by Azure, I suspect resolution problems trace to the same infrastructure issue. Maybe GitHub runners having trouble to resolve domain names because they're hosted on the same internal network. Say dns lookup resolves to some private ip address, because injected by kubernetes or something, but the container only allowed access to public ip addresses. Or something like that, just speculation.

## Seve — 2026-07-29T01:22:16.626000+00:00

haha idk about that haha

## Seve — 2026-07-29T01:22:21.883000+00:00

that would make the issue much bigger than us

## astrimid — 2026-07-29T01:28:04.828000+00:00

maybe it only reproduces in combination with how bun does DNS resolving or ipv6 issue

## astrimid — 2026-07-29T01:28:33.371000+00:00

networking is very strange in general

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

found open issue that might be related or might be red herring: https://github.com/oven-sh/bun/issues/28817

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

but I suspect it's DNS if that git commit really exists

## astrimid — 2026-07-29T01:31:37.458000+00:00

there's some serious work on bun:
https://github.com/oven-sh/bun/pull/36295 probably related to that controversial rust rewrite

## astrimid — 2026-07-29T01:35:24.245000+00:00

also, "resolve" could be either "can't resolve DNS name" or "can't resolve npm package", need to check bun source code to be sure.

But yeah, might be simpler to just get rid of that git sha1 dep and publish an npm package

## astrimid — 2026-07-29T01:35:49.700000+00:00

but npm also might have DNS resolution problems due to reasons above

## Seve — 2026-07-29T01:47:41.939000+00:00

yea the npm package is now published

## Seve — 2026-07-29T01:47:43.942000+00:00

nightmare haha

## astrimid — 2026-07-29T16:57:50.166000+00:00

It doesn't look like core update workflow is working.
Attachment: image.png — https://community.tscircuit.com/media/1532069654342926456

## astrimid — 2026-07-29T17:00:17.278000+00:00

the very bun install is not working

## astrimid — 2026-07-29T17:01:09.607000+00:00

why there's no lock file in core?

## astrimid — 2026-07-29T17:04:18.377000+00:00

no Update @tscircuit Package triggers since yesterday

## astrimid — 2026-07-29T17:07:54.010000+00:00

Why this workflow wasn't autodeleted when the workflow file was deleted https://github.com/tscircuit/eval/actions/workflows/update-deps.yml

## astrimid — 2026-07-29T17:10:50.714000+00:00

Ok. eval is a downstream of core:
https://github.com/tscircuit/eval/actions/workflows/update-tscircuit-core.yml

## astrimid — 2026-07-29T17:11:14.965000+00:00

what triggers core?

## astrimid — 2026-07-29T17:14:24.585000+00:00

calculate-packing, circuit-json, schematic-trace-solver, props, ngspice-spice-engine, matchpack - any of those npm releases should trigger core

## astrimid — 2026-07-29T17:19:28.336000+00:00

ok, those packages is where the pattern breaks. apparently, core isn't being auto-updated by its dependencies

## astrimid — 2026-07-29T17:20:45.066000+00:00

core triggers eval: https://github.com/tscircuit/core/blob/f69f522dbd485bf115370e55bd3d9d34cdddb298/.github/workflows/bun-pver-release.yml#L34-L41

## Seve — 2026-07-29T17:24:34.655000+00:00

yea core generally can't auto-update due to too many snapshots

## astrimid — 2026-07-29T17:40:08.492000+00:00

I think renovate/dependabot are the only reliable way to sync up automatically without hardcoding dependency tree in all the workflow files

## astrimid — 2026-07-29T17:47:59.266000+00:00

There are two alternatives:
- polling: every period of time a workflow runs that checks new releases of any of depdendencies (requires looking into package.json/bun.lock and comparing with npmjs released version)
- external server: I guess the original purpose of  release-tracker? https://github.com/tscircuit/core/blob/main/.github/workflows/on-merge-inform-release-tracker.yml
could be extended to track latest npm versions and triggering subscribers, but that just pushed the dependency graph to that external server

Could be a hybrid: external server funs out any release events to all the packages on tscircuit org and each repo individually tracks whether it cares about this repo.

## astrimid — 2026-07-29T17:52:27.053000+00:00

Another idea:
```
# Using GitHub CLI (gh) to find all org repos depending on '@tscircuit/core'
gh api -X GET search/code \
  -f q='org:tscircuit filename:package.json "@tscircuit/core"' \
  --jq '.items[].repository.name' | sort -u
```

## astrimid — 2026-07-29T17:57:56.657000+00:00

or a custom bot
Attachment: image.png — https://community.tscircuit.com/media/1532084780986925197

## astrimid — 2026-07-29T17:59:14.555000+00:00

but this is overengineering. how about trying out dependabot or renovate?

## astrimid — 2026-07-29T18:00:48.430000+00:00

renovate seems superior, but not sure what their pricing policy
Attachment: image.png — https://community.tscircuit.com/media/1532085501400584352

## astrimid — 2026-07-29T18:20:22.407000+00:00

the problem with dependabot and renovate, they have a limit on frequency of update.

we want instant trigger with cron fallback:
Attachment: image.png — https://community.tscircuit.com/media/1532090425832374322

## astrimid — 2026-07-29T18:22:05.320000+00:00

alternatively, each repo just does its own auto-update loop

## astrimid — 2026-07-29T18:22:49.062000+00:00

the trade off is the more repos you have, the more API workload is spent vs simplicity of maintaining dep versions

## astrimid — 2026-07-29T18:25:11.121000+00:00

so instead of having `M x N` trigger workflows, we have `M to 1` (notify) and `1 to N` (fun out) workflows.

## astrimid — 2026-07-29T18:34:30.835000+00:00

As a POC, I could write a workflow that searches tscircuit npm/github org every hour and submits PRs for any outdated dependencies owned by tscircuit. Or, for starter just a bash script you run locally. I wonder if such already exists?

## Seve — 2026-07-29T18:56:15.236000+00:00

we already switched from renovate/dependabot, did not work fast enough or well enough

## Seve — 2026-07-29T18:56:30.665000+00:00

we're already essentially in a custom bot situation

## astrimid — 2026-07-29T19:04:09.125000+00:00

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

## astrimid — 2026-07-29T19:04:45.266000+00:00

massive number. Might actually need caching and nighly run to build dep graph

## astrimid — 2026-07-29T19:05:02.947000+00:00

unless you already have something like that

## astrimid — 2026-07-29T19:16:13.346000+00:00

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

## Seve — 2026-07-29T19:30:41.258000+00:00

we're not trying to auto-sync everything tho fwiw

## Seve — 2026-07-29T19:30:52.217000+00:00

a lot of dependencies are just dynamically loaded like circuit-json-to-*

## astrimid — 2026-07-29T19:52:22.582000+00:00

can easily add exceptions

## astrimid — 2026-07-29T19:52:29.419000+00:00

or opt-in list

## astrimid — 2026-07-29T19:53:30.310000+00:00

the current situation of browsring through heterogenous intermixed workflows is absolutely unmanageable, imho

## astrimid — 2026-07-29T19:54:43.053000+00:00

could filter by repository topics, hardcode the auto-sync/opt-out list or whatever criteria you like

## astrimid — 2026-07-29T19:55:42.006000+00:00

https://github.com/astrimid/depcirk/actions/runs/30485086940/job/90688637113#step:4:50

## astrimid — 2026-07-29T19:56:46.539000+00:00

you could clone the repo or I could submit it whatever a best location for this script/workflow. Maybe `release-tracker` is a logical place?

## astrimid — 2026-07-29T21:09:06.835000+00:00

Here's a taste of how it could look like. What I like that it should be cleear what is being released, what are downstream dependents on this upstream dependency, who triggered what and a single place in code where you could debug the dependency tree for the whole org.

Next steps:
- amending npm release workflows to trigger this central workflow
- gradual opt-in or opt-out approach for downstream dependents
- implement actual step that do required package.json/bun.lock creates PR and enables auto-merge
- proper tracking of existing open PRs and closing superceeded ones
- finding a new place for it in tscircuit org 

Does it sound reasonable or I'm wasting my time?
Attachment: image.png — https://community.tscircuit.com/media/1532132890186354948
Attachment: image.png — https://community.tscircuit.com/media/1532132890647859200

## astrimid — 2026-07-29T21:27:06.218000+00:00

If it isn't obvious, I want to clarify the difference between lock file and package.json. The lock file is not a part of package release. So if the library has lockfile it's completely ignored during the resolution of app dependencies.

So for dependents where only lockfile required (e.g.`"*"`), you can absolutely skip new release (if it's not an app), as it would be noop. You should still trigger downstream propagation though, one step below.

This means the `update-packages.yml` needs to be extended to either trigger downstream (`bun.lock` only), release app (`bun.lock` only, but is not a library), release library (full `package.json` bump). So there would be 3 types of PR:  1. package.json bump 2. app bun.lock-based release 3. transient dependency update (pass down the package that initiated the release to downstream many hops below)

But for POC, this is probably overthinking.