Interesting approach in that repo… Using epe as the definitive version and having to blow away the js src makes it viewable, but it’s an awkward method. I see .epe as the final step, “production ready” so to speak. If there is a good way to build an epe from the js (the name, id and graphic, added to a escaped version of code) then that would reverse the order. I hope that’s the direction of your git RFC.
Making a pattern in non epe form into two parts might help: pattern.js is the code, and pattern.info is the rest. That would allow rebuilding an epe from the two parts: “build.or combine” script, and a blank template .info file would be easy: name, random id that doesn’t collide with existing ones, and empty image. Once that epe is loaded to a PB and a pattern is generated, and a real epe is built, then a “split” script would break that epe back into code and info, which would allow diffs, including to the info part, like name or id. (The image is the annoying part, as it’s binary encoded, and not really editable)
So let me revise the proposed two parts into three parts:
Pattern.js is the code
Pattern.info is the noncode: name, id
Pattern.gif (is that the image format? Whatever it is)
Run “build Pattern” would build Pattern.epe
Running “split Pattern” would do the opposite, and create/update from Pattern.epe into those 3 files.
In fact, a “push” script to take “raw” code and upload it would now be easy: build first, then upload. If the graphic (or code or name or id) is updated by PB, then running an “extract” script would download the epe and split into components, and any changes would be diffable.
Ideally an id change could be seen by the script as a potentially different pattern (“hey, the id is different, do you want to override this code or extract as a new/different pattern?”)