You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The emit-provider subcommand could benefit from a more defined approach to the provider generation process, particularly regarding the naming of the emitted Wasm binary. We have established a standard nomenclature for defining the instance namespace: javy_quickjs_provider_v<N>.
I propose enhancing the emit-provider tool to:
Allow users to specify the location where the binary will be written.
Emit a file name that adheres to our standard pattern: javy_quickjs_provider_v.
Additionally, since the provider is currently versioned independently from the CLI and other crates in this repository, I suggest that we properly name the provider in the release artifacts to ensure consistency with our established nomenclature.
What problem does it solve?
The motivation behind this proposal is twofold:
To clarify the association between provider versions and their corresponding javy CLI versions and releases.
To reduce the likelihood of errors when identifying and instantiating the provider module.
The text was updated successfully, but these errors were encountered:
What is the idea?
The
emit-provider
subcommand could benefit from a more defined approach to the provider generation process, particularly regarding the naming of the emitted Wasm binary. We have established a standard nomenclature for defining the instance namespace:javy_quickjs_provider_v<N>
.I propose enhancing the emit-provider tool to:
Additionally, since the provider is currently versioned independently from the CLI and other crates in this repository, I suggest that we properly name the provider in the release artifacts to ensure consistency with our established nomenclature.
What problem does it solve?
The motivation behind this proposal is twofold:
The text was updated successfully, but these errors were encountered: