Most of what we want out of our upstream tidy dependency is the Rust (Wasm) layout engine, plus a few of the TypeScript wrappers around it; and even the TypeScript bits are probably unnecessary if we just bite the bullet and write our own, as we currently have to create a Tidy layout and then tweak it for our unique “Primer” layout (e.g., for “right children”). This is surely inefficient.
Given that the upstream tidy package is a combination of the Rust bits, the handful of TypeScript types and functions that it exports, and then a bunch of extra code in the form of a Storybook and a test app; and given that upstream hasn’t published it to a package repo, and it’s therefore a bit difficult to use as a dependency, I think we should do the following:
Fork the package and rip out all but the Rust bits;
Properly package the Rust bits as an npm package (we need not publish this to Npm.js; GitHub’s org-level npm package repo will suffice); and
“Vendor” the few bits of TypeScript that we use, verbatim, directly into primer-app.
Once this refactoring is complete, we would only have a dependency on the Rust/Wasm code, which, as our new https://github.com/hackworthltd/nix-rust-wasm-npm repo demonstrates, is easy to hack, build, test, benchmark, and publish using our familiar Nix tools. There would be no need for us to maintain any of the extraneous bits of the current upstream package, and we would only have a single, straightforward dependency on our new Rust/Wasm-specific npm package. Vendoring the leftovers would put us on course to make a more efficient version of the TypeScript bits, tailored for our particular needs.
The risk is that if upstream adds major new features to tidy, those might be difficult to sync up. However, this scenario currently seems unlikely, and as I explained above, I think it’s much more likely that we will want to do our own tweaks/rewrites which are too implementation-specific to be useful to upstream.
Note that if we implement this plan, we will need to license the vendored bits of the upstream package in our code base separately from our own AGPL’ed code, but this will only require a small note in the project README and some boilerplate license comments in the vendored code in our tree.
dhess
commented
2 months ago
Most of what we want out of our upstream
tidydependency is the Rust (Wasm) layout engine, plus a few of the TypeScript wrappers around it; and even the TypeScript bits are probably unnecessary if we just bite the bullet and write our own, as we currently have to create a Tidy layout and then tweak it for our unique “Primer” layout (e.g., for “right children”). This is surely inefficient.Given that the upstream
tidypackage is a combination of the Rust bits, the handful of TypeScript types and functions that it exports, and then a bunch of extra code in the form of a Storybook and a test app; and given that upstream hasn’t published it to a package repo, and it’s therefore a bit difficult to use as a dependency, I think we should do the following:npmpackage (we need not publish this to Npm.js; GitHub’s org-levelnpmpackage repo will suffice); andprimer-app.Once this refactoring is complete, we would only have a dependency on the Rust/Wasm code, which, as our new https://github.com/hackworthltd/nix-rust-wasm-npm repo demonstrates, is easy to hack, build, test, benchmark, and publish using our familiar Nix tools. There would be no need for us to maintain any of the extraneous bits of the current upstream package, and we would only have a single, straightforward dependency on our new Rust/Wasm-specific
npmpackage. Vendoring the leftovers would put us on course to make a more efficient version of the TypeScript bits, tailored for our particular needs.The risk is that if upstream adds major new features to
tidy, those might be difficult to sync up. However, this scenario currently seems unlikely, and as I explained above, I think it’s much more likely that we will want to do our own tweaks/rewrites which are too implementation-specific to be useful to upstream.Note that if we implement this plan, we will need to license the vendored bits of the upstream package in our code base separately from our own AGPL’ed code, but this will only require a small note in the project
READMEand some boilerplate license comments in the vendored code in our tree.