Parts Bin — single-file component inventory with LCSC lookup and fab BOM export

[Parts_Bin]

If you have ever looked at PartKeepr or InvenTree and decided that standing up Docker and Postgres to keep track of four hundred parts was the wrong shape of answer, this is the other end of that.

It is one HTML file. No server, no build step, no dependencies, no account, nothing to keep updated. You open it and it works — off a disk, off a USB stick, or from wherever you serve it. The parts live in a JSON file you connect, or a private repo if you want two benches to agree. Nothing is uploaded anywhere. MIT.

The part of it I did not expect to be interesting: LCSC have no search endpoint open to anyone but their own site. If you want to look a part up by manufacturer number from outside, the only way in is to render their search page and read the product links off it — and a page assembled in the browser is a miserable thing to scrape. Whatever renders it hands back the page as it looked when it stopped waiting, which is the results sometimes and the empty frame they load into other times. The same search would work and then fail ten minutes later.

JLCPCB index the same catalogue and answer in JSON. No rendering, no scraping, no such failure mode, and about a second per lookup. That is where part-number search goes now, and every hit is read back and its real part number compared before it is offered — searching SRN4018-220M also returns NRSE4018-220M, which is a different part.

https://AJEngineering.github.io/parts-bin-app/ — opens with an example bin loaded, so every tab does something without you typing anything in.

What it actually does:

Knows what is in which drawer. Counts, alert levels, and a part split across two boxes written C1:25 + C6:20 and counted correctly in both.

Fills a part in from its LCSC code. Manufacturer, package, value, description and datasheet. Values come out in the bin's own convention rather than the supplier's running order — a capacitor as 25V 4.7uF X5R ±10%, a resistor as 10kΩ. Parts that have no value in the usual sense are left blank on purpose, rather than having "72" scraped out of "72 MHz".

Checks a BOM against the shelf and tells you how many boards you could build today, then exports for JLCPCB, PCBWay, NextPCB or PCBGOGO with each house's own column headings. Written as real .xlsx, because a CSV opened in Excel turns 0402 into the number 402 and the fab is then looking at a footprint that does not exist.

Twenty-five bench calculators, each drawn as a schematic that redraws as you type. The cable one sizes a run for an allowed drop, reports the voltage actually reaching the load, and asks for the conductor temperature rather than assuming 20 °C — copper gains 0.39 % per degree and a loaded cable is not cold. It gives watts per metre and refuses to print a temperature rise, because that depends on insulation, bundling and ambient. Same reason the AWG table has diameter, section and Ω/m and no current rating: a number I invented there would be believed.

Source is one file with the reasoning written into the comments, and the readme has a ten-line Cloudflare Worker if you would rather the lookups went through your own relay than a public one.

https://github.com/AJEngineering/parts-bin-app

Bug reports and feature requests are welcome on the issue tracker.

[Parts_Bin]

The first post described it. This is what it does, and you can reproduce it in ten seconds: open the demo, press Load the example bin, then BOM → Check against the bin.



Ten lines, all ten on the shelf, two boards buildable today. That last number is the one worth having: it is the smallest have ÷ need across the board, so it answers what you can build now rather than what you own. Here the resistors and capacitors are good for hundreds of boards and two connectors cap the whole thing at two — the sort of thing you would rather learn before ordering the PCBs than on the day you sit down to build.

The four buttons below it write that same board out for JLCPCB, PCBWay, NextPCB or PCBGOGO, each with that house's own column headings, as .xlsx rather than CSV so 0402 still reads 0402 when the fab opens it.

https://ajengineering.github.io/parts-bin-app/

[PlainName]

Nice. Not what I need (and already have one) but I can imagine where it would be very useful. 

[Parts_Bin]

Thanks. What are you using? Genuinely asking — if it does something this does not, I would rather know than guess.

And the second half of your post is the more interesting one to me: where did you picture it being useful? I built it for my own bench, so I am curious which other ones you had in mind.

[PlainName]

Parts&Vendors - a pretty old and now unobtainable thing using Microsoft Access. Developer died some time back so it's never going to get any updates, and you can't get a license now or even download it anyway. But worked for me and, importantly, still works - doesn't need fancy frameworks, specific OS, online anything. I am sure it will still be keeping track when I'm no longer around to forget where I put stuff

[voltsandjolts]

Around year 2000 I was at a company that revolved around Parts&Vendors. It was actually pretty good, intuitive and stable. Pity they didn't open source it so it could live on.

[PlainName]

Yes, but perhaps the chap had other priorities around the end time. The family kindly kept the site up for users to access downloads for quite a while. But shows the problems with apparently decent software and companies that rely on online.

Used to use TheBrain, which was fairly unique in the way it could show associations between disparate entities. About a decade ago they switched to using a single database for all projects, which I couldn't agree with - I want all data for a project to be copyable to a single place, unencumbered but non-project data. So I stuck with the version I had. Just changed PC to find I can't activate it now - they took down the activation server just after I bought it! Never noticed because I didn't need to re-activate. Even though they now give away their new version (which I can't use because of the database aspect) they are unwilling to help me get my paid-for version going.

Sorry, bit of digression there

[abeyer]

Took a look at this for a while today, and would have to agree that it feels very nice and like it's probably a great fit for your particular process/setup... but also not for me.

If you have ever looked at PartKeepr or InvenTree and decided that standing up Docker and Postgres to keep track of four hundred parts was the wrong shape of answer, this is the other end of that.

While I certainly understand the sentiment there, and don't necessarily disagree, I think what you're running into is you're correct that most people don't need/use/want most of things in the big "bells and whistles" tools, but the 20% of them that you use, the 20% I do, and the 20% someone else does are all different sets of features & requirements. So any attempt to build the small trimmed-down version is either going to limit its audience to a much smaller group, or start collecting new features until it grows to become yet another big bloated one.

[Parts_Bin]

PlainName — that is the argument for the whole thing, put better than I put it.

Parts&Vendors still runs because it asks nothing of anyone: no activation, no server, no subscription. What killed your TheBrain licence was not the software. It was a machine in someone else's building being switched off.

So: one HTML file, MIT. There is no activation to fail and nothing for me to switch off. If I stop maintaining it tomorrow the file keeps working, and anyone can fork it — which is the part Parts&Vendors never got, and why yours is unobtainable to everyone but you. Your parts live in a JSON file you keep. Open it in Notepad in twenty years and it is still a list of parts, which is more than an .mdb will promise you.

Being straight about the one online dependency: filling a part in from its LCSC code needs their site, and their catalogue is not something I can put in the file. Everything else — the drawers, checking a BOM, the exports, the calculators — makes no network request at all. I checked rather than assumed: the page loads nothing external. No CDN, no fonts, no analytics.

abeyer — you are right about the dynamic, and it is the usual way these end.

Your dichotomy is: limit the audience, or accrete features until it is another bloated one. There is a third road, and it exists only while the thing stays small enough to read. Everyone's 20% can be different because everyone can change it. One file, no build step, no framework, no dependencies, 4,956 lines of ordinary JavaScript. An engineer who wants a field I never thought of can add it in an evening and still be running their own copy.

That is not a claim it will suit you. It probably will not. But fork it means something different here than it does when the answer is a compose file and a schema migration.

[abeyer]

Forking and changing things definitely occurred to me, and I poked around the code for a bit. Unfortunately it seems like there were some design decisions that felt like they were going to be far more intrusive to unroll than just adding a new field. Which leads to...

Your dichotomy is: limit the audience, or accrete features until it is another bloated one. There is a third road, and it exists only while the thing stays small enough to read. Everyone's 20% can be different because everyone can change it.

I don't disagree with that third approach... but long lived forks with anything more than trivial changes have their share of problems, too. There is some commitment needed to either accept that you fork once and never pull in future upstream changes, or commit to ongoing work keeping abreast of those changes so you don't fall too far out of sync. LLM agents perhaps help lighten that load, but don't completely remove it. And they tend to work a lot better if they have a solid automated test suite to rely on (not to mention the value of them to the developer in the first place.) So if you really want to encourage/support that use case, I'd suggest investing in building out some tests.

One file, no build step, no framework, no dependencies, 4,956 lines of ordinary JavaScript.

I get the appeal there, even if I don't entirely agree. I won't debate the merits in general, as a lot of that is a matter of taste, but another suggestion would be that maybe just the calculators part breaks out into a separate file. It's fairly standalone in both use and implementation, and I think arguably makes for a more disruptive workflow/ux to load it in the rest of the SPA anyway. If it were its own page that opened in a new tab/window outside the SPA, it would help to logically decompose the code, would make for a nicer workflow when using it, and would make it easier for someone to drop in their own choice in cacluators if they have something else they already use.

[Parts_Bin]

Done, and thank you for it — the measuring was the useful part. The calculators were 1,400 of 4,956 lines, and the whole block reached into the inventory exactly once. That is arithmetic rather than taste, so out they came: about 1,500 lines lighter once the wiring went with them, into a repository of their own.

The Calc tab is a link, not a frame. Loading them across would have meant the inventory fetching from a host it does not control, which is the failure mode PlainName described earlier in this thread. So both pages still make no network request of their own, and anyone working offline keeps the two files side by side.

What the split cost, since it is only fair to say: a computed value no longer tells you how many of that part are sitting on your shelf. That note needed a shelf to look at.

It goes up in a day or two, so no link yet.

The tests are not written and I am not going to pretend otherwise. That is the next piece of work.

And I would still like to know which design decisions stopped you. A third of the file just left. If the thing that blocked you is structural, this is the cheapest moment it will ever be to fix.

[gamalot]

I was honestly stunned when I saw this thread because over the past few days I've also been asking Claude to help me build a home electronics parts inventory web app, and the wild part is Claude even suggested the exact same name: PartsBin.

I actually tried doing something similar last year, but back then I was using Copilot before it became as powerful as today's AI tools. I gave up pretty quickly after starting. This time it feels completely different.

[Parts_Bin]

Same tooling here, and it produced the same two words — so the name is less of a coincidence than it looks. The timing still is one: same problem, same week.

Your point about last year lands, too. What changed is not that any of us got better at writing the code.

Yours is plainly the other shape of the answer, and I mean that as the compliment it is. Per-category parametric filters — resistance, tolerance, power and T.C. all first-class on a chip resistor — is the thing mine deliberately does not do. It searches text and compares one value, and that is the ceiling. Users, documents and a stock log say you are building for more than one bench, which is a different problem from the one I had.

Two questions, if you feel like answering. How are you storing attributes that differ from category to category — a table per category, or key/value rows against the part? And I noticed USD and AUD sitting in the same list: are you keeping the currency each part was bought in, or converting on the way in?

Good luck with it, and post it when it is ready.

[gamalot]

Two questions, if you feel like answering. How are you storing attributes that differ from category to category — a table per category, or key/value rows against the part? And I noticed USD and AUD sitting in the same list: are you keeping the currency each part was bought in, or converting on the way in?

For the first one: I actually haven't written a single line of code yet. So I asked Claude how it would structure category specific attributes, and I'll share the screenshot of its answer here.

As for the second question, I always record new components using the currency at the time of purchase. It's just a habit I've kept since ten years ago when I was still tracking my inventory in an Excel sheet.

[JohanH]

This looks nice.

I maintain my hobbyist inventory in a LibreOffice spreadsheet, but I've been looking for alternatives. I installed Part-DB (https://docs.part-db.de/) on a virtual server some time ago, but I've been too lazy importing all the parts. The nice thing with Part-DB is that it has support for many different parts vendors. There's even a scan function, to import parts from barcodes etc. On the other hand I still hesitate, because what if my server goes down, or I have to move the system in the future. I keep backups on a NAS, but it anyway would cause a lot of work to set up the server again.

My advice would be to keep this as simple as possible, it looks perfect right now when you can just run it like this without installing dependencies, servers etc.

[gamalot]

This looks nice.

I maintain my hobbyist inventory in a LibreOffice spreadsheet, but I've been looking for alternatives. I installed Part-DB (https://docs.part-db.de/) on a virtual server some time ago, but I've been too lazy importing all the parts. The nice thing with Part-DB is that it has support for many different parts vendors. There's even a scan function, to import parts from barcodes etc. On the other hand I still hesitate, because what if my server goes down, or I have to move the system in the future. I keep backups on a NAS, but it anyway would cause a lot of work to set up the server again.

My advice would be to keep this as simple as possible, it looks perfect right now when you can just run it like this without installing dependencies, servers etc.

I'm letting AI handle literally everything: building and deploying the app, importing all my old Excel inventory data, and setting up automatic backups both to my local machine and to cloud.

[Parts_Bin]

gamalot — that schema is a better answer than the question deserved, and the part that matters is the one that is easiest to overlook: storing value_text and value_number side by side. That column pair is the whole difficulty of parametric search, solved once, at write time.

Mine has no schema to put a number in, so it parses the number back out of 25V 4.7uF X5R ±10% every time somebody asks for >=1uF — and it has to be told which unit to read, because that string holds four numbers. Yours will never have to guess. That is the honest trade for having no database.

The per-category overrides are the right shape too. Inheritance with exceptions is what a component tree actually is.

One thing worth settling before the data goes in rather than after: what value_number holds for an attribute that is not a single number — a temperature range, a tolerance of +80/−20%. Much cheaper to answer now than at 1,326 rows.

And recording in the purchase currency is right. A converted figure is a snapshot of a rate you no longer have.

JohanH — that hesitation is the third time in this thread somebody has described the same failure, and it is the entire reason mine has no server. Your parts would live in a JSON file beside the page, which is closer to your spreadsheet than to Part-DB.

Straight about what you would give up, though: no barcode scanning, and one distributor rather than many. If either of those is what keeps you on Part-DB, this will not replace it.

[gamalot]

One thing worth settling before the data goes in rather than after: what value_number holds for an attribute that is not a single number — a temperature range, a tolerance of +80/−20%. Much cheaper to answer now than at 1,326 rows.

For cases like ranges or multi‑value numeric attributes, my app doesn't currently have a way to handle them, but adding a dedicated "range" attribute type shouldn't be difficult.

I would like to keep the app relatively simple and easy to use, rather than fully featured or overly powerful at this stage.

[gamalot]

I feel like the app is already good enough for someone like me as a personal user, so I decided to stop adding new features and just publish it on GitHub.

https://github.com/gamalot/bindex

[Parts_Bin]

Published beats perfect, and stopping when it is good enough for you is the harder half of that. Congratulations. Also, bindex is a better name than the one we collided on.

Three things in there I would not have arrived at.

Stock held in lots, each with its own location, purchase price and currency. That is a proper answer to the currency question I asked you — better than the one I was fishing for. A part bought twice at two prices stays honest about which is which, and mine cannot say that at all.

Facets that show only the values present in the current result set. That is the hard half of parametric search, and the half most implementations quietly skip.

The pick list. Cart while browsing, print sorted by location, walk the shelf once, confirm the lot in a single stock-out. Mine has the buying direction and nothing whatsoever for the building direction. That is a real gap, and I had not noticed it until I read your readme.

[Parts_Bin]

gamalot — the pick list I have gone and stolen, so it is only fair to say so. Mine had the buying direction and nothing at all for the building direction, and I had not noticed until I read your readme.

The starting point was already there: paste a BOM and it says what is on the shelf, what is short, and how many boards you could build today.



What was missing was the step after it. One row per drawer rather than per line, since a part split across two boxes is two stops on the walk, sorted by box number so the shelf is walked once and never doubled back on. What is ticked is what leaves the bin, so a drawer you open and find empty is simply left unticked. It prints with the boxes empty, to be ticked with a pen.




abeyer — the calculators are out, into a repository of their own. This file is 3,932 lines now rather than 4,956.

https://ajengineering.github.io/circuit-calcs/

The tests are still not written. I said that a week ago and it is still true.

[gamalot]

No worries at all, feel free to take anything you find useful. If the pick list helps your project, I'm glad it was worth borrowing.

[Parts_Bin]

gamalot — thank you, and it is only fair to report back what came of it.

The pick list is in and it has changed how I use my own bin. One row per drawer rather than per line, sorted by box so the shelf is walked once, and what stays unticked simply does not leave the bin — so a drawer you open and find empty costs you nothing but a pen stroke. I had the buying direction and nothing at all for the building direction, and I would not have noticed the gap if your readme had not been sitting there describing it. Borrowed, credited, and better than what I would have invented.


abeyer — the tests are written. I said twice in this thread that they were not, so it is worth saying plainly that they now are.

Code: [Select]

node test.js
No dependencies, because the thing being tested still has none. The unexpected part is that the most useful checks turned out to be geometric. It draws every option of every dropdown, 167 diagrams, and measures each one for parts that overlap, wires that run through a symbol, labels crossed by a wire, labels printed too close to read apart, and text outside the frame. That found six faults nobody had seen by looking at the page: an amplifier input that landed outside its own box, a return wire straight through the ADC symbol, two arrows wearing their own labels across themselves.

There is a mutation harness alongside it that puts each fixed fault back one at a time and checks the suite notices. Fifteen for fifteen. A test that cannot fail is not a test.

You were right that it is the thing that makes a long-lived fork survivable, and it was the right order to do it in: four shipped arithmetic errors turned up on the way through. One of them was a boost converter's ESR ripple computed with the buck's expression, about three times optimistic since the day it was written.

The whole thing has its own thread now, with what it gets wrong and where it refuses to answer:

Circuit Calcs — 41 bench calculators in one HTML file

There were 25 of them when they were a tab in here. On their own they have grown to 41, which is roughly the argument for having split them.

[booscrawl]

I love watching Claude puppetteer people.

[Parts_Bin]

I love watching Claude puppetteer people.

Claude is a tool, not a ventriloquist.

If you have a specific technical criticism I am listening. If not, the line is
cleverer as a joke than as feedback.