Skip to content

Releases: noppa/xmllint-wasm

v5.1.0

14 Oct 18:00

Choose a tag to compare

5.1.0

Add support for xmllint's --stream option, which is useful when
validating large XML files.
Supporting this feature required compiling libxml2 with reader support, which
adds about 30K, or 4%, increase to the wasm binary size.

Closes #27.

v5.0.0

20 Jun 00:29

Choose a tag to compare

Officially supported Node.js version is raised from 12 to 16, which is a breaking change.

Upgrades libxml2 to v2.13.8, which slightly changes some of the error messages.

Optimizes the XML file input reading, by switching from Emscripten FS.createDataFile to
FS.writeFile.
I'm not 100% certain if this is actually a breaking change or not,
but this could possibly be a breaking change if you previously passed in
file contents that were strings, but not from an utf-8 encoded file. Try
passing the non-utf8 encoded data as a Buffer instead, which we now also explicitly support
in options.xml[i].contents.

Optimizes the output reading, by switching from Emscripten Module.stdout API (which apparently
pushed one byte of output at a time to an array), to the print API, which pushes more reasonably
sized chunks of strings to the output string.
This fixes a crash #20 "Invalid array length on "large xml" file",
that occurred on very large outputs.
In some cases, the old output handling resulted in output not having a last line break at the end of
output. In the new output, the last line break is always included. This could break some tests
where you expect some exact output that didn't previously have said line break in the end.

We now validate that XML and Schema file names do not start with a dash (-), or contain
a space and a dash ( -), which would cause xmllint to interpret the file name
as a command line option. File names could be user-inputted, so this change is to
prevent end users from accidentally or maliciously changing the expected behaviour of
the validation. It is recommended, though, to also do stricter validation of file names
if you accept them from user input.
This is a breaking change if you previously passed in file names that started with a dash.
There is a new option disableFileNameValidation to disable this validation if you want
to keep the old behaviour and accept any kind of file name.

Adds new optional option modifyArguments, which allows you to arbitrarily add
or modify the command line arguments that are passed to the xmllint command. The
option is a function that receives the current arguments as an array, and should
return a new array of string arguments.
Closes #22.

v5.0.0-alpha Optimize file input and stdout output

19 Mar 10:15

Choose a tag to compare

Attempt to fix #20 by using two more performant Emscripten APIs, FS.writeFile instead of Fs.createDataFile+intArrayFromString, and for output Module.print instead of Module.stdout.

I don't think this should be a breaking change, for most people at least, but I'm doing a major version bump anyway because I think maybe the createDataFile vs writeFile change could cause trouble if the input XML had some other encoding than utf-8. FS.writeFile assumes utf-8 when the input is string.

TODO: We now also accept Buffer in the XML file contents, which should be reflected in types. Also, more testing is needed before release, I haven't checked browser usage at all yet.

4.0.2

30 Sep 15:55

Choose a tag to compare

Minor improvement to error handling (#19, 012dde34b).

4.0.1

24 Jul 22:46

Choose a tag to compare

Fix to the TypeScript type definitions (#16).
No runtime changes.

4.0.0

21 Mar 23:06

Choose a tag to compare

Add two new options, initialMemoryPages and maxMemoryPages, to control
how much memory the WebAssembly module allocates by default and is allowed
to allocate for the validation.
PR #16, fixes issue #8.
Thanks @MLSTRM!

The "breaking change" here is that we also raise the default maximum
memory cap from the old implicit 16MiB to double of that, 32MiB.
With this new default, you may not even need to use the maxMemoryPages option
yourself, as 32MiB is probably already high enough for quite a lot of use cases.

In some very memory constrained environments, this raised limit could impose
a problem if it causes the main process to run out of memory, so that's why
I'm calling it a breaking change. For most applications, though, this should
not be a problem. You can opt into the old limit by setting

  maxMemoryPages: 16 * xmllint.memoryPages.MiB,