I ran the contents of that part file through FritzingCheckPart. Here is a summary of what it reported, and what I noticed doing a manual inspection and smoke test in Fritzing.
The copper0 and copper1 layers (groups) in the pcb svg should be reversed. copper0 should be ‘inside’ copper1, instead of the other way around.
The “breadboard” layerId specified in the fzp part definition does not exist in the matching svg image. This will “appear” to work in Fritzing, but exporting a sketch to an svg image will not include the part. The first/outer wrapper group element should be changed tThose should be put intributes for connectors in the schematic view, which do not actually exist in schematic svg. These should exist in the svg. They are used to give Fritzing a reference point, to “snap” wires to. Without this, wires attached to the connectors will be drawn to the middle of the connector pin line, instead of to the end.
The connnector«n»terminal elements should be circles, rectangles, or lines centered at the end point of the corresponding connnector«n»pin elements that wires should connect to. Usually with fill and stroke = “none”, so they are not visible.
In the pcb svg, connector0pad and connector8pad have been created as “rect” elements. That does not have a radius, so exporting to gerber will not create drill holes for those connectors. The way to create square (or other non-circular THT pads) is to use a circle element for the the connector«n»pad elements, then add additional (usually path) elements to expand the circle. Do not cover the hole in the circle with the extra graphics, but do overlap with the ring (stroke) of the circle as much as possible, so that Fritzing will detect the extra graphics as being part of the pad. The extra graphic elements do not have a pad id.
This board has 3 GND pins. A ‘bus’ entry should be created for those, so that Fritzing knows that anything wired to one of those pins is electrically connected to the other GND pins as well.
The schematic svg should be scaled so that the connector pins on each side are (exactly) 0.1 inch apart, and 0.1 inch long (sometime 0.2 inch long). The 2 rows of pins should be a multiple of 0.1 inch apart. Specifically, the connector«n»terminal elements should all be exact multiple of 0.1 inch in both x and y directions from every other connector«n»terminal element. This lets the part position cleanly in relation to other parts, and connection wires will line up nicely.
With the family for the part defined as “esp32”, the variant should be something else. “variant 1” is too likely to conflict with some other part in the same family. “esp32 camera” could work, although that is still likely to not be unique for other esp32 “sibling” boards. The combination of property names and values needs to be unique for every loaded Fritzing part. Otherwise Fritzing has now way to pick the correct one to use. Or actually, the user has no way to tell Fritzing which one to use. Internally Fritzing uses the moduleId value, which also has to be unique.
If there is a web page for this part, the fzp metadata should include a <url> entry pointing to it. This should be a place to find out more information, even if that is just a page to order the part. Data sheet type web pages are another option.
The “important” ones from that, the ones that will cause using the part to “break” during use (export), are the missing layers and no circle for the pcb pads. The rest are more cosmetic or limiting. The part will work, but the sketch might not be as clean as it could be, or the part can not be loaded at the same time as some other esp32 family parts.