dart-lang
web_generator: Publish a pre-release on pub.dev?
@nikeokoronkwo @srujzs Should we consider publishing (a pre-release of) this package?
I don't have a use-case myself. But potential users can find and use it much easier via pub.dev than via a git dependency.
We've always made tools such as FFIgen and JNIgen available on pub.dev with 0.x versions and marked as experiment after they were created as GSoC projects.
@nikeokoronkwo @srujzs Should we consider publishing (a pre-release of) this package?
We will still need to add/adjust some things before we can make it usable outside of this repo. Currently, using the package requires you to have it cloned in your working directory.
I like the idea of a prerelease until we're stabilized, but we probably have code that makes assumptions on paths like Nike mentions. We may also want the executable to be consistent with FFIgen and JNIgen if it isn't already before publishing.
We may also want the executable to be consistent with FFIgen and JNIgen if it isn't already before publishing.
For FFIgen and JNIgen we're switching away from a bin/ with a yaml config, and instead using a Dart API. The FFIgen one is already refactored, JNIgen is still pending. Example of the refactored API:
- https://github.com/dart-lang/native/blob/main/pkgs/code_assets/example/sqlite/tool/ffigen.dart
The general idea is to have a XxxGenerator that's an object literal with all the declarative configuration (that would have been in the yaml), and then have a generate method that takes context such as a logger, file system, process manager, etc. The Dart API is easier to document than YAML, and it enables configuration such as renaming to be simple callback functions instead of regex replacements.
(Kind of off topic, but the web_generator name was chosen for saying that it generates bindings for the web? Wouldn't it theoretically be possible to generate bindings and use them with nodeJS? js_gen? js_interop_gen? We've been using the "gen" for all the other generators such as FFIgen, JNIgen, and SwiftGen. For SwiftGen we've just chosen SwiftGen as name, even though it'd be Swift Interop Generator. Maybe for JS that would be a bit too confusing as we also have a JS backend for Dart. Happy to stick with the current name if you prefer, don't mind me asking questions.)
(Kind of off topic, but the web_generator name was chosen for saying that it generates bindings for the web? Wouldn't it theoretically be possible to generate bindings and use them with nodeJS? js_gen? js_interop_gen? We've been using the "gen" for all the other generators such as FFIgen, JNIgen, and SwiftGen. For SwiftGen we've just chosen SwiftGen as name, even though it'd be Swift Interop Generator. Maybe for JS that would be a bit too confusing as we also have a JS backend for Dart. Happy to stick with the current name if you prefer, don't mind me asking questions.)
I asked Srujan about this (quite early on): I was thinking of the name "jsigen". What do you think?
(Kind of off topic, but the web_generator name was chosen for saying that it generates bindings for the web? Wouldn't it theoretically be possible to generate bindings and use them with nodeJS? js_gen? js_interop_gen? We've been using the "gen" for all the other generators such as FFIgen, JNIgen, and SwiftGen. For SwiftGen we've just chosen SwiftGen as name, even though it'd be Swift Interop Generator. Maybe for JS that would be a bit too confusing as we also have a JS backend for Dart. Happy to stick with the current name if you prefer, don't mind me asking questions.)
I asked Srujan about this (quite early on): I was thinking of the name "jsigen". What do you think?
I'm afraid JSI is not a well-known acronym (unlike JNI). So I think I like spelling out "interop" a bit more. package:js_interop_gen generates for dart:js_interop. Which is the same spelling in both: js_interop. It seems that _generator is quite common on pub.dev, so I could be convinced of package:js_interop_generator as well. But I kinda like the "ring" of ending in gen. That's just my two cents.
For FFIgen and JNIgen we're switching away from a bin/ with a yaml config, and instead using a Dart API.
Ah yeah Nike mentioned this earlier. Surfacing a Dart API instead is fine with me.
Kind of off topic, but the web_generator name was chosen for saying that it generates bindings for the web?
Yes, I mostly wanted to separate web out from its generation code and that made the most sense at the time. We then added the .d.ts generation code into the same package so that we can share the AST easily and work towards a general JS interop generator.
I'm fine with package:js_interop_gen as well. We now own package:js_interop so it helps with the consistency there too.
We then added the .d.ts generation code into the same package so that we can share the AST easily and work towards a general JS interop generator.
Ah, yeah historical reasons! Let's do package:js_interop_gen then. Then we got a bunch of gens in the interop space! 🚀
I'm looking forward to putting this into the hands of our users! Let me know if you want an extra pair of eyes on it before you publish.
Another thing is that we have three scripts in the bin/ folder for the package. The JS interop gen script is possibly the only script users may want to work with, but wanted to mention this just to know if we will keep the other scripts as-is.