> On Feb 14, 2017, at 6:00 PM, Alex Harui wrote:
>
> An Emitter could change the goog.requires in every file, and even use a
> different require system like RequireJS.
This might be a good solution. The initial compilation could be optimized for
Node (and just require() all the assets) and it
The compiler supports special [JSModule] metadata for Node so that it emits
the correct require() calls. It might be possible to make use of this for
projects that target Node and other contexts. The compiler will probably
need some tweaks, though.
Here's an example:
package {
[JSModule]
publ
On 2/13/17, 11:51 PM, "Harbs" wrote:
>Fair enough… ;-)
>
>The problem is creating libraries which can be used both in the browser
>and in Node.
>
>Unless we add another set of swcs for Node with a new COMPILE::NODE
>conditional, I don’t see how we can generalize FlexJS to be usable for
>both.
>
Fair enough… ;-)
The problem is creating libraries which can be used both in the browser and in
Node.
Unless we add another set of swcs for Node with a new COMPILE::NODE
conditional, I don’t see how we can generalize FlexJS to be usable for both.
Maybe adding COMPILE::NODE is the right answer.
On 2/12/17, 3:17 PM, "Harbs" wrote:
>I just added a CompressionUtils class which uses ByteArray on the Flash
>side and pako on the javascript side.
>
>It uses inject_html to link to the js because I don’t know of a better
>way to currently do this.
>
>I don’t like this approach for a number of
I just added a CompressionUtils class which uses ByteArray on the Flash side
and pako on the javascript side.
It uses inject_html to link to the js because I don’t know of a better way to
currently do this.
I don’t like this approach for a number of reasons:
1. It hardwires the link into the ge
