Hi everyone!
I was wondering if there’s any built-in API for compressing multiple files together (e.g. multiple asset renditions) into a single archive (ZIP, tarball, etc) in Adobe XD?
One common use case is uploading files to a web server which would otherwise require them to be uploaded one by one.
If there’s no such API, I guess it makes sense to file a Feature Request?
Thank you!
There’s no API for this yet, but you should be able use a JS-only zip compressor module like https://www.npmjs.com/package/jszip. (I haven’t tried this yet, though.)
Definitely worth a feature request though!
Thank you @kerrishotts ! I’ll take a look at possible options in Node.js land.
Are there any updates on that? As I understand Xd relies on zip a lot as xd file format is a zip.
FYI I’ve changed this topic to a feature request since it’s come up multiple times.
@gdreyv Thanks for following up with us. This is in our backlog but please note that we generally prioritize feature requests with more votes.
@kerrishotts, jszip is not working, node modules not working either. Any other ideas ?
Works fine for me, what exactly doesn’t work?
Just:
import zip from "jszip";
const archiver = new zip();
const content = await file.read({ format: uxp.storage.formats.utf8 });
archiver.file("file-name.json", content);
const content = await archiver.generateAsync({ type: "uint8array", compression: "DEFLATE", compressionOptions: { level: 9 } });
await archive.write(content, { format: uxp.storage.formats.binary });
where archive and file are the uxp File instances.
It should be mentioned here that this approach (the import syntax and simply importing "jszip" without a path requires some sort of bundling system (like webpack) to be in place.
Otherwise, @samodostal, you’ll have to save the “corresponding” JS file of the library somewhere in your plugin and refer to it with something like
const jszip = require('./libs/jszip/jszip');
It could also be that jszip actually depends ons some sort of build tool (I currently don’t have the time to check this, sorry), meaning you could only use it with such a build system in place.
I hope this helps,
Happy coding,
Pablo
Thanks for replying,
We already figured it out. Basically, the same way you did with JSZip.
Usually, if an a feature is compiled into the environment it is usually orders of magnitude faster compared to a JIT interpreted language.
In one similar environment the JS library took 500ms and the native embedded feature added later took 5ms.
I completely agree with you that XD misses a lot of really important native functionality like zip or json export. But as they fix critical bugs for months, implementation of such features will take decades (check the date of the first post) 
Indeed. I meant to quote this:
If an external library works then there’s less need to have it built in.
The main point I meant to make in the thread is to point out to readers is that there are a few differences when including it natively in the API vs including it externally at runtime as part of the discussion.