Wishlist: one file per symbol in eeschema libraries.

(I'm not a developer.)

There will be new file format and library format layout similar to footprints in version 6.0.

This is in the v6 roadmap [1].

[1] http://docs.kicad-pcb.org/doxygen/v6_road_map.html#v6_sch_sweet

Didn't wayne realize it is possibly not a good idea and reversed this? I seem to remember a mailing list message or a message in some bug. (Something about the fact that symbols can reference each other via the inheritance stuff and this does not work well if they are in separate files)

This should still be doable, just put the same symbol family in a single file - that is, only symbols that lacked an inheritance gets a separate file. Or use symlinks.

What you really wish for is a good way to merge libraries. Having every symbol in a separate file simply offloads this task to the operating systems file browser. (At the cost of raising implementation complexity of symbol to symbol interactions and increased loading times.)

The same task could also be implemented within kicad instead. For example by allowing the import symbol feature to select multiple symbols from a source file. Or even an intelligent system that uses version control tools to be able to say "this symbol is newer in that file do you want to use that?". And i am sure some dev can come up with something even better than i could. Just accept that maybe your proposed solution to a problem might not be the one that will be chosen in the end.

One file per symbol may or may not happen due to the inheritance design of the new file format. It doesn't make sense to create multiple files for a single symbol so it's most likely that the new symbol library file format with be multiple symbols per file like the current file format. The other reason is performance. Currently there are over 14K symbols. The load times would be terrible if each symbols were in a separate file. This is why we implemented caching for the footprint libraries. I suppose we could implement a hybrid solution where we could support multiple or single symbols per file that are part of a library implemented as a folder of files. I'm still working that out with the new file format so nothing is out of the realm of possibility at the moment.

If a native KiCad solution is preferred, we will need some kind of symbol library installer that will merge and update libraries without wiping custom additions.

One idea I have here if symbols are to be put in a single file is instead of separate files, is to put all the libraries in something like a SQLite database (or for design teams, a shared instance of MariaDB,) and distribute exported symbols as SQL files that updates the database. As of the installer, it comes with an empty but preconfigured SQLite database file for new installations, and a huge SQL file that contains all symbols as exported SQL.

KiCad bug tracker has moved to Gitlab. This report is now available here: https://gitlab.com/kicad/code/kicad/-/issues/2490