Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
I need to better account for compression differences with my tests, as right now it depends on which zlib compression implementation you write your NBT files with, will depend on whether the tests will pass or not. This should be excluded I think, I thought it would be perfect to ensure that the compressed versions are the exact same as well, but I don't think that's worthwhile if you can check the raw bytes themselves anyways. Say, to make this file recompiled with the matching zlib layouts, and with the newly updated empty ListTag types ( #40 ), simply opening it with Dovetail and re-saving it didn't work, because it looks like Chrome's zlib backing is different than Node's, even though they both use V8, and they are both on the same macOS ARM machine. So I can rule those things out. I already knew this was the case between Linux and macOS, but I thought this wasn't different between Chrome and Node on the same machine for some reason. I guess I assumed that they would *happen* to be using the same compression implementations, even if they may be two separate installations of that. That would make sense, I didn't expect them to use the same install of it. Just the same or nearly same versions. Another weird thing I encountered. Since I discovered the zlib differences between Node and the browser, I thought I'd use my local global install of NBTify in the CLI to resave the file, using Node as well. That actually encountered an error, and it was only happening with the `--pipe` flag to write it back to the original file. I'm not sure what it was about, that was frustrating though. Going to look into debugging that one. #25
- Loading branch information