Replaces `serde_json` parsing with `jsonc-parser` throughout the
codebase, enabling support for **comments** and **trailing commas** in
all JSON files including `.project.json`, `.model.json`, and
`.meta.json` files.
MSRV bumps from `1.83.0` to `1.88.0` in order to
use the jsonc_parser dependency.
<p dir="auto">in <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="2636858743" data-permission-text="Title is private" data-url="https://github.com/rojo-rbx/rojo/issues/989" data-hovercard-type="pull_request" data-hovercard-url="/rojo-rbx/rojo/pull/989/hovercard" href="https://github.com/rojo-rbx/rojo/pull/989">#989</a>, we changed Rojo's version number on the master branch to 7.4.4. This is a little odd, because 7.4.4 is already released, is diverged from the master branch, and we are not working towards 7.4.4 on the master branch. If we're going to spend time on this, I think we should use a more appropriate version number.</p>
<p dir="auto">This PR changes the version number to 7.5.0-prealpha, since Rojo's master branch is currently undergoing development towards 7.5.0. We will most likely <strong>not</strong> be making a release of this version - the only intent is better clarity for those running Rojo's latest master.</p>
Due to the rewrite of the plugin's core sync loop and the change for the
Notify backend on MacOS, along with all the other changes in 7.4.0, it
makes sense for us to use a release candidate before actually cutting a
proper `7.4.0` release.
This modifies Rojo's build script to throw a fit if we're building a
plugin with a semver incompatible version. In the process, it moves the
version of the plugin to a file named `Version.txt` that's parsed at
runtime. This should be minimally invasive but it's technically worse
for performance than the hardcoded table and string we had before.
This feels better than a CI check or just manually verifying because it
makes it physically impossible for us to forget since Rojo won't build
with it being wrong.
TOML maps well to Lua, is easier to read and write than JSON, and is
commonly used by Roblox tools.
Use cases:
* Put game, plugin, or library config in a toml file
* Sync in toml files generated by tools
* Sync in config files for tools so that the game can double-check that
the config file has been followed. (e.g. check that packages match
versions specified in wally.toml)
This PR brings two performance improvements to the `rojo sourcemap`
command:
- Use `rayon` with a small threadpool to parallelize sourcemap
generation while still keeping startup cost very low
- Remove conversions to owned strings and use lifetimes tied to the dom
instead, which mostly improves performance with the
`--include-non-scripts` flag enabled
From my personal testing on an M1 mac this decreases the sourcemap
generation time of our games by 2x or more, from ~20ms to ~8ms on one
project and ~30ms to ~15ms on another. Generation is pretty fast to
begin with but since sourcemaps are heavily used in interactive tools
(like luau-lsp) a difference of a couple frames can be great for ux.
* Use WeakDom::into_raw for faster snapshot generation from models
* Make compute_patch_set take snapshots by value
* Stop deferring property application in apply_patch_set
* Use InstanceBuilder::empty to avoid extra name allocations
* Git dependencies, skip dropping ServeSession
* Use std::mem::forget instead of ManuallyDrop
* Switch to latest rbx-dom crates.io dependencies
* Update other dependencies
