Yes, it's possible to create for Node.js typedefs in that style. For instance, here are a couple of typedefs for Node.js modules that I needed in my asconfigc tool (which builds vscode-as3mxml projects from the command line):
https://github.com/BowlerHatLLC/asconfigc/blob/master/externs/minimist/src/minimist.as https://github.com/BowlerHatLLC/asconfigc/blob/master/externs/mkdirp/src/mkdirp.as These use special [JSModule] metadata that the Royale compiler understands. If a typedef with @externs also has [JSModule], the compiler will add a CommonJS require() call in the generated JavaScript: var minimist = require("minimist"); Other JS module types could potentially be supported, but CommonJS is all that I got around to implementing. - Josh On 2019/05/02 18:17:49, Dany Dhondt <[email protected]> wrote: > Hi Josh, > > Aren’t most of the packages just functions? > In ES6, you’d import packages as > Import { myFunct, myVar } from ‘my-package’ > In older javascript you’d: > const myPackagePointer = require(‘my-package’) > > So your ‘fun’ example sounds like heaven to me! This is exactly what we need. > > About Typescript: do we need that at all? I think, but maybe this goes beyond > my technical knowledge, all node packages are compiled into plain old > javascript functions. Typescript is only needed for authoring the packages. > Once compiled there’s no trace of Typescript at all. If this is indeed true, > then we shouldn’t bother about Typescript at all, and just concentrate on > incorporating the pure javascript libs. > > Dany > > > Op 2 mei 2019, om 19:57 heeft Josh Tynjala <[email protected]> het > > volgende geschreven: > > > > Just for fun, here's another way that you could create a typedef for hljs > > so that the highlightBlock() function is directly in a package (similar to > > flash.net.navigateToURL), instead of as a static method on a class: > > > > https://paste.apache.org/khVI > > > > If you did it this way, you'd need to import it before you can call the > > function, like this: > > > > import hljs.highlightBlock; > > > > Or this should work too, if you prefer: > > > > import hljs.*; > > > > And then you can call the function directly (without the hljs. prefix): > > > > highlightBlock(block); > > > > As you can see, the way that you choose to expose a JS library to > > ActionScript is pretty flexible. Some JavaScript libraries are just a > > function, and some have APIs that work more like classes. Depending on the > > library, one way may work better than the other. > > > > - Josh > > > > On 2019/05/02 17:48:49, Josh Tynjala <[email protected]> wrote: > >> Exactly right. When you create a typedef class, you're trying to simulate > >> how you would access the API as if you were writing in plain JavaScript. > >> You call hljs.highlightBlock() in JavaScript, so you need a class that > >> works the same way in ActionScript. > >> > >> Another option for organization would be to keep all of your typedefs in a > >> separate folder from your app's source files, and reference the typedefs > >> folder using the source-path compiler option. > >> > >> - Josh > >> > >> On 2019/05/02 16:23:45, Alex Harui <[email protected]> wrote: > >>> Hi Carlos, > >>> > >>> I don’t think hljs is in a package called "externs". In Josh's example, > >>> hljs was in the top-level package. And that's because hljs is found at > >>> runtime off of the global window object, not some sub-object called > >>> "externs". So, the hljs.as file containing the externs has to go in the > >>> root of a source-path, not in some folder called "externs" (which is why > >>> some folks will take the time to create a separate typedefs SWC so as not > >>> to clutter the root of their application's source directory). > >>> > >>> Then instead of "import externs.hljs", it should be "import hljs" (or > >>> shouldn’t be needed at all). > >>> > >>> HTH, > >>> -Alex > >>> > >>> On 5/2/19, 9:11 AM, "Carlos Rovira" <[email protected]> wrote: > >>> > >>> Hi, > >>> > >>> in my latest commit I added hljs extern class like Josh show in package > >>> externs in TDJ > >>> > >>> Then I didn't commit the following since is not working for me: > >>> > >>> 1.- In HighlightCode class (in utils package TDJ) > >>> > >>> added: > >>> > >>> import externs.hljs; > >>> > >>> changed the method highlightBlock to: > >>> > >>> COMPILE::JS > >>> /** > >>> * block is the element (WrappedHTMLElement) inside the component (the > >>> <code> tag) > >>> */ > >>> public function highlightBlock(block:Element):void > >>> { > >>> hljs.highlightBlock(block); > >>> } > >>> > >>> and running it I get: > >>> > >>> Uncaught ReferenceError: externs is not defined > >>> at utils.HighlightCode.highlightBlock (HighlightCode.as:53) > >>> at > >>> > >>> WelcomeSection.components.ExampleAndSourceCodeTabbedSectionContent.dataReadyHandler > >>> (ExampleAndSourceCodeTabbedSectionContent.as:138) > >>> at services.GitHubService.goog.events.EventTarget.fireListeners > >>> (eventtarget.js:284) > >>> at Function.goog.events.EventTarget.dispatchEventInternal_ > >>> (eventtarget.js:381) > >>> at services.GitHubService.goog.events.EventTarget.dispatchEvent > >>> (eventtarget.js:196) > >>> at > >>> > >>> services.GitHubService.org.apache.royale.events.EventDispatcher.dispatchEvent > >>> (EventDispatcher.js:71) > >>> at services.GitHubService.services_GitHubService_completeHandler > >>> (GitHubService.as:54) > >>> at > >>> org.apache.royale.net.HTTPService.goog.events.EventTarget.fireListeners > >>> (eventtarget.js:284) > >>> at Function.goog.events.EventTarget.dispatchEventInternal_ > >>> (eventtarget.js:381) > >>> at > >>> org.apache.royale.net.HTTPService.goog.events.EventTarget.dispatchEvent > >>> (eventtarget.js:196) > >>> > >>> What I'm doing wrong? > >>> > >>> thanks! > >>> > >>> > >>> El jue., 2 may. 2019 a las 18:02, Carlos Rovira > >>> (<[email protected]>) > >>> escribió: > >>> > >>>> Hi Josh, > >>>> > >>>> I think this piece of knowledge you just exposed here is key for the > >>>> success of Royale. > >>>> > >>>> I'll try to use this in TDJ to experiment with it and will use in the > >>>> blog > >>>> example I plan to do. > >>>> > >>>> thanks! > >>>> > >>>> > >>>> El jue., 2 may. 2019 a las 16:36, Josh Tynjala (<[email protected]>) > >>>> escribió: > >>>> > >>>>>> Users can't do this, they required that Royale framework devs add > >>>>> typedefs to the typedefs repo and wait to next SDK release. What does > >>>>> not > >>>>> seems very useful. > >>>>> > >>>>> Users can create their own typedefs from scratch. > >>>>> > >>>>> I just created a quick example for hljs, that exposes the > >>>>> highlightBlock() function: > >>>>> > >>>>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FdIq0&data=02%7C01%7Caharui%40adobe.com%7C91b9c474703f4878a7b408d6cf18e064%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924103085455525&sdata=J8d1PlqvyFfdIqVdpH0y%2FaXV%2BZzoYxm3w6Q9eo%2BIH7c%3D&reserved=0 > >>>>> > >>>>> Basically, the class needs an asdoc comment with the @externs tag (this > >>>>> is something that comes from Google Closure compiler, which we use to > >>>>> create release builds) and the compiler should handle the rest. > >>>>> > >>>>> As I understand it, you don't even need to create a SWC library for > >>>>> custom typedefs. Recently, Alex mentioned that the mxmlc compiler is > >>>>> smart > >>>>> enough to handle a source file as long as it has the @externs tag. > >>>>> > >>>>> - Josh > >>>>> > >>>>> On 2019/05/02 09:34:37, Carlos Rovira <[email protected]> wrote: > >>>>>> Hi, > >>>>>> > >>>>>> to sumarize (let me know if I'm wrong), the current ways to integrate > >>>>>> an > >>>>>> existing library are 3: > >>>>>> > >>>>>> 1.- access vía brackets notation: This is the most easy and direct, an > >>>>>> example is TourDeJewel in class utils.HighlightCode > >>>>>> > >>>>>> var hljs:Object = window["hljs"]; > >>>>>> hljs["highlightBlock"](block); > >>>>>> > >>>>>> but this one is not what we really want since we are going with Roayle > >>>>> and > >>>>>> AS3 to get type checking and strong typing. So this, although useful is > >>>>> not > >>>>>> what we really want to use in out Apps, but since we want to maintain > >>>>> the > >>>>>> dynamic aspect of the language it could be very useful sometimes > >>>>>> > >>>>>> 2.- using typedefs > >>>>>> > >>>>>> This will be the next step to use a real type and dot notation, but > >>>>> seems > >>>>>> not easy or direct. > >>>>>> Users can't do this, they required that Royale framework devs add > >>>>> typedefs > >>>>>> to the typedefs repo and wait to next SDK release. What does not seems > >>>>> very > >>>>>> useful. > >>>>>> > >>>>>> In the other hand we'll need to know how to extend current typedefs > >>>>> since > >>>>>> don't know if we have docs about this. Until now I added to > >>>>>> "missing.js" > >>>>>> file fo now, but this doesn't seems a valid path since it lacks > >>>>>> organization, separation, and a way for all people contributing to know > >>>>> wha > >>>>>> we have, what can be added and where, if not we'll find in time lots of > >>>>>> code very difficult to maintain. > >>>>>> > >>>>>> Yishay and Josh talked about to use TypeScript, but seems that is > >>>>> already > >>>>>> explored by Josh but not a valid path since will be very difficult to > >>>>>> maintain. > >>>>>> > >>>>>> 3.- wrapping libraries > >>>>>> > >>>>>> This is how we did with MDL. This will be recommended when we want to > >>>>>> integrate existing libraries with Royale to make it work with our APIs > >>>>> in a > >>>>>> more seamless way. But the problems is that this is very laborious. Can > >>>>> be > >>>>>> useful for some concrete libraries and we should do when needed (the > >>>>> case > >>>>>> is MDL). But the problem is that this not solve the problem of our > >>>>>> users > >>>>>> that need to integrate a existing library themselves in a quick way. > >>>>>> > >>>>>> Let me know if you know other way. > >>>>>> > >>>>>> For me method 1, is ok to do the work, but doesn't make us justice. > >>>>>> method 2 should be the main one if there's a fast and easy way... I'm > >>>>>> missing something here? Can users create typedefs themselves? > >>>>>> method 3 can be useful for us or for users (doing their own libs, and > >>>>>> eventually can share with us to add to official royale repo and sdk) > >>>>>> but is something not fast at all and not as convenient and direct as > >>>>> method > >>>>>> 2, and will require maintenance as libs change. > >>>>>> > >>>>>> Could we agree that this is the currently available ways in Royale now > >>>>> to > >>>>>> use external JS libs? > >>>>>> > >>>>>> thanks > >>>>>> > >>>>>> -- > >>>>>> Carlos Rovira > >>>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C91b9c474703f4878a7b408d6cf18e064%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924103085455525&sdata=OsyQPnn3ssPp8pErMDXuknTLLiy0HOaMolUbNiOh8Cw%3D&reserved=0 > >>>>>> > >>>>> > >>>> > >>>> > >>>> -- > >>>> Carlos Rovira > >>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C91b9c474703f4878a7b408d6cf18e064%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924103085455525&sdata=OsyQPnn3ssPp8pErMDXuknTLLiy0HOaMolUbNiOh8Cw%3D&reserved=0 > >>>> > >>>> > >>> > >>> -- > >>> Carlos Rovira > >>> > >>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C91b9c474703f4878a7b408d6cf18e064%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924103085455525&sdata=OsyQPnn3ssPp8pErMDXuknTLLiy0HOaMolUbNiOh8Cw%3D&reserved=0 > >>> > >>> > >>> > >> > >
