[ALOY-1722] Cannot make calls to alloy programmatically via require
| GitHub Issue | n/a |
|---|---|
| Type | New Feature |
| Priority | None |
| Status | Open |
| Resolution | Unresolved |
| Affected Version/s | n/a |
| Fix Version/s | n/a |
| Components | n/a |
| Labels | n/a |
| Reporter | Brenton House |
| Assignee | Feon Sua Xin Miao |
| Created | 2020-02-24T19:57:09.000+0000 |
| Updated | 2020-03-09T11:20:45.000+0000 |
Description
The alloy plugin seems to support requiring alloy via require('alloy') but it errors out as the args are not properly configured.
The alloy executable should be creating a new instance of alloy and using that so that no matter if you are calling alloy from CLI or programmatically via require('alloy'), they would both behave the same way.
Titanium CLI should also behave the same way but that should be a separate ticket.
[~bhouse] this is something we are aiming towards, but I don't think it should be classed as a bug as Alloy wasn't designed in this way. There's an open improvement ticket (ALOY-879) to expose Alloy as a module, and the work [~jvennemann] is doing will help us get there.
[~eharris] - I changed it to "New Feature". I am not sure if the work the Jan is doing will help as I am not sure that is focused on non-webpack usage.
[~bhouse], that work will be folded back into the main alloy package, see https://github.com/appcelerator/alloy/pull/952.
[~bhouse], do you have specific use case what you want to do with Alloy programmatically? I was only interested in using the Alloy compiler, so that's the only thing i worked on and made that available as a standalone package. As Ewan already mentioned, the compiler is fully compatible with existing Alloy code and will be folded back into the main repo. I just added Webpack support on top of it.
Inside the Titanium plugin that executes alloy, I want to require alloy (instead of opening it in a new process).
Some more info would be great. Why do you want to require it? Just to avoid spawning a new process? And then kick off an Alloy build as usual?
:D "Just" A lot of this goes to following best practices and correcting old mistakes. We never should have built a tool that we would have to spawn a new process for and have to serialize all input when it was going into a Titanium plugin. This can be avoided by always having your alloy cli code call require on the main alloy file. That way the alloy cli supports both. As it is right now, we have no context sharing between Titanium and Alloy. Titanium knows all kinds of info about native modules, etc and the only way for Alloy to get that information is to reparse files and recreate the work that was done in Titanium.
That "just" was indeed a huge understatement, but i was only interested if thats "all" you wanted to do or anything else was going on ;) So, yeah, ideally Alloy would have a Node API that the CLI just wraps and passes all info into. The thing is that Alloy does not really has such an API and everything is designed around Alloy being called as a CLI as the main entry. As Ewan already mentioned, this is something we are aiming towards, but there is a long way ahead of us. This could be something for ALOY-1719.
It's not very complicated. Give me an hour or less and I will create a PR for it.
[~jvennemann] [~eharris] PR done: https://github.com/appcelerator/alloy/pull/956