Export WXZ files

[akirk]

Description

This adds WXZ support to the extension.

How has this been tested?

Use the extension to export from Wix, it will now generate a ZIP file.

While this now switches over the fileformat completely, it's actually a matter of using the right library, so it could be reasonably easy to add a config option.

Testing

Use the wxz-valdiator.php from https://github.com/akirk/wxz-tools, this is a possible output (showing that we don't support validation objects there):

WARN objects/1.json: Unknown schema for "objects".

wix-export.zip is valid, 1 warning was encountered.
The file contains these types of data:
- users: 1
- terms: 4
- posts: 26

Types of changes

Breaking change: This will generate a ZIP file instead of a WXR XML file.

huge props @pento for figuring out how to generate a valid ZIP file!

[pento]

Nice job on getting this up and running so quickly!

I have a few brief thoughts on where it's at so far:

• The remapping done on post objects is a cute way to get it up and running quickly, but I'd be inclined to switch over to WXZ entirely, and just remove the WXR library. I don't think there's any benefit to keeping it around, particularly as the browser extension is still under heavy development, with no back compat requirements.
• It'd be useful to think about how we could provide the schema files everywhere they're needed (currently developed in wxz-tools, but used here, and in the importer plugin that @jeroenpf is building). I suspect this is a use case for providing the schema as a package.
• Similarly, it'd be useful to think about how testing tools can be shared, too. Providing the tools in wxz-tools as a package is one approach, though I do wonder how well that would play with the current Jest-based tests. Perhaps a little Jest library to handle WXZ snapshots (along the lines of jest-pdf-snapshot) would work here.

[akirk]

The remapping done on post objects is a cute way to get it up and running quickly, but I'd be inclined to switch over to WXZ entirely, and just remove the WXR library. I don't think there's any benefit to keeping it around, particularly as the browser extension is still under heavy development, with no back compat requirements.

I agree, just that I was planning to do this in a second iteration. This is now a version that can produce both WXZ and WXR (with a few small code replaces from wxz to wxr) and the next PR would remove WXR and the remapping.

The remapping done on post objects is a cute way to get it up and running quickly, but I'd be inclined to switch over to WXZ entirely, and just remove the WXR library. I don't think there's any benefit to keeping it around, particularly as the browser extension is still under heavy development, with no back compat requirements.

👍

Similarly, it'd be useful to think about how testing tools can be shared, too. Providing the tools in wxz-tools as a package is one approach, though I do wonder how well that would play with the current Jest-based tests. Perhaps a little Jest library to handle WXZ snapshots (along the lines of jest-pdf-snapshot) would work here.

This and the previous point speak for bundling all of this in a Github org of its own.