vshaxe
Feature request / discussion : init project command
I would like to see added a haxe init [lib|platform] command that will initialize an empty project.
For instance:
haxe init js
would create the following:
- Main.hx with a
class Main { static function main() {} } - an hxml with
-main Main -js output.js - an index.html which includes output.js
- the .vscode/tasks.json that does compile it
- the .vscode/launch.json that allows to run an debug it
We could do that by providing "templates" directory that contains these files so they are directly copied. We could have an optional project name haxe init js MyProject that replaces Main.hx by MyProject.hx. I actually did something similar for heaps here: https://github.com/HeapsIO/heaps/tree/master/samples/templates
Library support
Additionally, I would like also to be able able to run haxe init heaps hl
In that case VSHaxe would:
- locate heaps library (if not installed install it, if no haxelib setup done, prompt for it -- first time install)
- check if there's a "templates/hl" directory. if yes, uses these template files. if no, give the list of available templates in error ((heaps)/templates/
) - if only
haxe init heapsis done, look at "(heaps)/templates/default" directory
Having a standardized way of creating projects (and sample projects / demos ideally, too) definitely seems desirable. Many libraries currently roll their own solutions for this (lime / openfl, flixel-tools, etc) that are all invoked differently.
In that case VSHaxe would locate heaps library
Wouldn't it be easier for Haxe to try and locate the library? I guess this depends on whether or not Haxe will still depend on Haxelib in the future.
haxe init
It makes sense to have a simple command that can also be invoked manually by the user, but I wonder if we should also have a JSON-RPC version of this that is more flexible / powerful for IDEs (since we're already going "all-in" with JSON-RPC in the new display protocol).
We could do that by providing "templates" [...] I actually did something similar for heaps here:
So how would that work exactly? It seems like you're using hxtemplo there, but different libraries (already) have different ways of doing things.
I think something that gives total freedom akin to run.n would be good. As we're moving away from Neko though, it would make more sense to use an Init.hx file that is run through eval (which Haxelib actually already optionally supports for run scripts too). Libs like Lime and Flixel that already have project creation tools can just use Init.hx to invoke those, which makes supporting haxe init trivial.
Regarding init for demos / samples (lime-samples, openfl-samples, flixel-demos...) - this would need to be a two-step process. Currently lime create / flixel create gives you a list of projects, and then you can pick one of them. This means haxe init heaps would have to become haxe init heaps project for a "standard" / empty project, because haxe init [lib] would give you a list of templates to choose from. Vshaxe could present this list via the "quick-pick"-UI.
Wouldn't it be easier for Haxe to try and locate the library? I guess this depends on whether or not Haxe will still depend on Haxelib in the future.
I was thinking that vshaxe would simply call haxelib path <libname>
It makes sense to have a simple command that can also be invoked manually by the user, but I wonder if we should also have a JSON-RPC version of this that is more flexible / powerful for IDEs (since we're already going "all-in" with JSON-RPC in the new display protocol).
I was thinking to have this command be a VSCode vshaxe command, not a haxe compiler command
So how would that work exactly? It seems like you're using hxtemplo there, but different libraries (already) have different ways of doing things.
The goal is to generate "startup" project, so basic var replacing (using templo or split/join) is good enough.
Ah, haxe init sounded a lot like a compiler command. ;) That's a bit less exciting, that would mean that this would just be a VSCode-specific solution...
Wouldn't it make sense to have something more generic / standardized similar to haxelib run (such as haxelib init)? Right now this sounds like some in-between solution where vshaxe just assumes that libs will have a template directory or something, but it's not actually standardized.
Also, I'm not sure if we want a hxtemplo dependency in vshaxe. :P
You don't need hxtemplo, simply haxe.Template with is std lib :) and yes the idea is to allow libraries to provide vshaxe support. We can name the directory .vstemplate if you prefer, but I think it's a lot better than nothing :)
On Thu, May 31, 2018 at 9:26 PM, Jens Fischer [email protected] wrote:
Ah, haxe init sounded a lot like a compiler command. ;) That's a bit less exciting, that would mean that this would just be a VSCode-specific solution...
Wouldn't it make sense to have something more generic / standardized like haxelib run (such as haxelib init)? Right now this sounds like some in-between solution where vshaxe just assumes that libs will have a template directory or something, but it's not actually standardized.
Also, I'm not sure if we want a hxtemplo dependency in vshaxe. :P
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/vshaxe/vshaxe/issues/229#issuecomment-393649153, or mute the thread https://github.com/notifications/unsubscribe-auth/AA-bwFeNDfChDAXzXk40rSRVHChMjWnRks5t4EPPgaJpZM4USuTa .
I think we should support the creation of sample projects as well, which means some way of obtaining a list of projects to display in the UI and letting the library do more to resolve the available projects (maybe running some code through eval / with haxe --run). For a lot of projects, at least lime / openfl / flixel, samples live in separate haxelibs.
Note: I also don't want to enforce the use of haxe.Template. E.g. for Flixel, I just want to keep using what we already have, and not create / maintain a redundant copy of the template with haxe.Template just for vshaxe. Other library authors probably feel the same.