Closed saulecabrera closed 2 months ago
cc/ @surma since we chatted about using Intrinsics, I decided to give this a try as part of adding a faster JSON implementation.
Do we plan to remove the stream I/O and console APIs into a plugin later after we've figured out a common extension mechanism?
...and the soon-to-be-introduced JSON
functions. That would be the ideal outcome I believe, given that they introduce non-standard functionality and it will also allow us to test our extension mechanism.
This change primarily rewrites the current APIs using "Intrinsics" as defined by rquickjs.
This change has several objectives:
Refactor the structure of the Config and its relationship with the Runtime to pave the way for a truly extensible and configurable engine. The way Intrinsics are exposed in rquickjs simplifies (i) enabling a granular configuration experience of the native intrinsics, which was not entirely clear how to achieve before, and (ii) adding custom APIs as intrinsics.
Enhance how our configuration operates: the previous model assumed an almost static configuration setup, allowing only limited, non-straightforward customizability from the CLI in the future. This was mostly modeled per API and not as a global aspect of the runtime. Our recommended approach for users needing functionality beyond what was provided was to fork or recreate their own version of the CLI/APIs. A telling sign of this issue is that the configuration parameters were almost never used in any of the APIs. This PR paves the way for greater extensibility, which will be facilitated by threading configuration options from the CLI in a follow-up PR; this method will also allow for opting-in to non-standard functionality via a CLI flag, helping us avoid issues like the one noted here: https://github.com/bytecodealliance/javy/issues/628.
Along the way, I had to make several changes to make all this work; the most relevant ones are: (i) deprecating the
javy-apis
crate (ii) enabling all the APIs by default and (iii) reworking a bit theConsole
implementation.The reasoning to deprecate the
javy-apis
crate is mostly around: (i) the fact that we're revamping our extensilbity model in the near fuiture and (ii) the complexity around cyclical dependencies:javy
exposes rquickjs and given that the cofiguration is tied to the runtime,javy
needed to depend onjavy-apis
but the other way around was also true. I decided not to spend too much cycles on this mostly given point (i) above.There are still things to follow-up on after this PR, namely
docs
Checklist
javy-cli
andjavy-core
do not require updating CHANGELOG files.