I have written a library called redux-async-action-reducer. I have written it in typescript. I want to add flow definition to it.
Is there any way I can keep it along with my library rather than creating a separate and putting it in flow-typed?
Something like d.ts for flow defintion files?
You could ship your library with a .js.flow file alongside your package entry point. In your case (since your package entry point is dist/index.js you would create a file at dist/index.js.flow.
Flow will then treat this like a normal source file. You'll have to remember to put // #flow at the top. You can either write functions and classes with stubbed out implementations, or use declare (e.g. declare export function foo(x: string): string;, similar for class).
Note that this will actually be different than a library definition file -- Flow will treat it like source code.
Flow-typed is the preferred way to distribute libdefs. Using .js.flow files can lead to issues when Flow makes breaking changes between versions. However, since you will be distributing a hand-curated interface, rather than shipping your entire library source as .js.flow files, that issue will be mitigated.
Related
What is the difference between resource and library file in robot framework?
I searched google but couldn't able to find the answer
The resource file content is in the Robot Framework syntax. When it's imported in a suite, you can use all its keywords and variables, defined in the corresponding sections. Also all its imports (other Resource and Library it defines in the Settings section) are now available for usage.
The libraries on the other hand are (usually) written in the Python language. They can be ones installed through pip, or standalone scripts or modules. In the simplest case, all public functions of a module (more specifically - not-hidden) are available as keywords to be used in the suite. For more advanced usage (scope, state upkeep), they have to follow specific structure (usually accomplished through classes, and using identifiers/decorators expected by RF).
There is a third type of import, for which you haven't asked but I'm adding for completeness - the Variables files. Their format is once again Python code, which makes them quite versatile and powerful compared to vars defined in RF syntax (you can set the variables' content through complex programming constructs).
One caveat to keep in mind with them - the framework expects every attribute of the module to be a variable, and makes it accessible in your suite; this includes even other modules the file imports :). Thus you have to hide them through the _ name suffix (or, abuse this side effect for silent imports in some exotic cases :)).
I've included links to the relevant sections of the user guide, for further information.
I understand that you can create a separate yang file (Something like a textual Convention to store syntax values for MIBS)and import it into another yang file to make the data more organised and structured, but I can't seem to understand what the include statement does differently?
Does it "import" the entire file into the file that's including it - and if so would this be read before the file including it...?
Please help :)
YANG relies heavily on a concept known as "namespaces", which stems from XML naming conventions. Each namespace has a unique resource identifier and allows definitions (in different namespaces) to have same names at same definition levels while avoiding name clashes. When you define a YANG module, you are actually defining a namespace.
An import statement is used to access definitions from a foreign namespace (another module), while an include statement introduces a mechanism that allows a single namespace (single module) to be logically split into several files, conveniently named module and submodules. For includes, there is always exactly one module file, which includes all submodule files that belong to it. A submodule may only belong to a single module and may not be imported (directly). To an importing module, a module that includes submodules, looks like a single entity. Submodules may include eachother, but with YANG version 1.1, this has become unnecessary, since a submodule immediately gains access to all definitions in all submodules and the module they all belong to. In YANG version 1 you had to explicitly include a submodule to use definitions from it in another submodule, while never being able to access definitions in the module to which they belonged.
An import does not "inline" definitions into the importing module, while an include does exactly that. Importing a module gives you access to its top-level definitions (typedefs, groupings, idenitites, features and extensions) and allows you to use schema node identifiers that identify nodes in the imported module (for the purpose of augmentation and deviation, for example).
Definitions from a foreign namespace are always accessed via a prefix, which are part of an import statement's definition. Definitions that come from includes do not need to be prefixed when used, and if they are, are prefixed with the including module's (or submodule's) prefix.
YANG "compilers" usually process these files when they hit either an import or an include statement. They need to process them in order to be able to resolve definitions in body statements of the defining module. That is why these statements are required to appear in a module's header section.
There is an entire section in YANG specification dedicated to modules and submodules, where you can read more on the topic.
I read on this answer the following statement:
"Keep in mind that the compiler can and does move code from one chunk into other chunk output files if it determines that it is only used by that chunk."
Is there any way to switch that off?
I have a 'main' chunk and an 'optional' chunk, and I'm finding the code from the optional chunk is being moved entirely into the main.
My optional code will only be called from the main code, but only if it's determined that we actually want to load the optional stuff (based on a flag that's external to both.)
I want to minimize the size of the main code for cases where the optional stuff isn't needed, but it doesn't seem to be possible with closure as far as I can see.
EDIT:
To split the code I use the -chunk options on the (java) commandline. The 'main' one I point at several folders ('src/Infra/*.js' etc) and use 'auto' for the numFiles for the chunk. The 'optional' I point at three specific files, no wildcard, and specify 3 as numFiles.
To load the 'optional' script the 'main' writes a script tag to the page and has a Promise resolve when it loads. 'optional' is supposed to instantiate the class it defines, and push a reference to that instance to an array in the global namespace, then main reads the ref from the array, and calls an init() method on it, passing in some dependencies.
Is there a better-supported (and equally compact) way of doing it?
EDIT2: in case anyone has a similar issue, I resolved it using the "nameCache" feature of uglifyjs, so the separate components don't necessarily need to be compiled at the same time.
The compiler does not move code "up" the module graph. What's happening is the compiler somehow believes that symbols defined in your optional chunk are directly required.
This most frequently occurs because you are using dependency management and modules. When the compiler sorts dependencies, if any of the "optional" files are directly imported via require for CommonJS, import for ES6 or goog.require for Closure. In this case the compiler adds them to the main module.
To be more specific, I'd actually have to see code.
I have a rather big library with a significant set of APIs that I need to expose. In fact, I'd like to expose the whole thing. There is a lot of namespacing going on, like:
FooLibrary.Bar
FooLibrary.Qux.Rumps
FooLibrary.Qux.Scrooge
..
Basically, what I would like to do is make sure that the user can access that whole namespace. I have had a whole bunch of trouble with this, and I'm totally new to closure, so I thought I'd ask for some input.
First, I need closurebuilder.py to send the full list of files to the closure compiler. This doesn't seem supported: --namespace Foo does not include Foo.Bar. --input only allows a single file, not a directory. Nor can I simply send my list of files to the closure compiler directly, because my code is also requiring things like "goog.assers", so I do need the resolver.
In fact, the only solution I can see is having a FooLibrary.ExposeAPI JS file that #require's everything. Surely that can't be right?
This is my main issue.
However, later the closure compiler, with ADVANCED_OPTIMIZATIONS on, will optimize all these names away. Now I can fix that by adding "#export" all over the place, which I am not happy about, but should work. I suppose it would also be valid to use an extern here. Or I could simply disable advanced optimizations.
What I can't do, apparently, is say "export FooLibrary.*". Wouldn't that make sense?
Finally, for working in source mode, I need to do goog.require() for every namespace I am using. This is merely an inconvenience, though I am mentioning because it sort of related to my trouble above. I would prefer to be able to do:
goog.requireRecursively('FooLibrary')
in order to pull all the child namespaces as well; thus, recreating with a single command the environment that I have when I am using the compiled version of my library.
I feel like I am possibly misunderstanding some things, or how Closure is supposed to be used. I'd be interested in looking at other Closure-based libraries to see how they solve this.
You are discovering that Closure-compiler is built more for the end consumer and not as much for the library author.
If you are exporting basically everything, then you would be better off with SIMPLE_OPTIMIZATIONS. I would still highly encourage you to maintain compatibility of your library with ADVANCED_OPTIMIZATIONS so that users can compile the library source with their project.
First, I need closurebuilder.py to send the full list of files to the closure compiler. ...
In fact, the only solution I can see is having a FooLibrary.ExposeAPI JS file that #require's everything. Surely that can't be right?
You would need to specify an --root of your source folder and specify the namespaces of the leaf nodes of your file dependency tree. You may have better luck with the now deprecated CalcDeps.py script. I still use it for some projects.
What I can't do, apparently, is say "export FooLibrary.*". Wouldn't that make sense?
You can't do that because it only makes sense based on the final usage. You as the library writer wish to export everything, but perhaps a consumer of your library wishes to include the source (uncompiled) version and have more dead code elimination. Library authors are stuck in a kind of middle ground between SIMPLE and ADVANCED optimization levels.
What I have done for this case is maintain a separate exports file for my namespace that exports everything. When compiling a standalone version of my library for distribution, the exports file is included in the compilation. However I can still include the library source (without the exports) into a project and get full dead code elimination. The work/payoff balance of this though must be weighed against just using SIMPLE_OPTIMIZATIONS for the standalone library.
My GeolocationMarker library has an example of this strategy.
is there a simple way to generate a JAR file, that contains only the classes that depend transitive from a certain "main" class (reflection omitted of course).
I want to provide a little part of my application to someone else but do not want to export the whole application.
Thanks,
M.
Probably the easiest approach is using a tool like yGuard which "...provides elaborate code shrinking functionality through dependency analysis." This would also solve the same problem where you give it an entry point, and it performs dependency analysis to work out which classes can be excluded from the Jar.
However, I have throught about this problem myself a few times and fancied having a go at it myself for the challenge. All it would take would be to parse the import statements of Java source files and build a dependncy graph of how the classes interact with each other. Each reference from the main class should be recursively scanned until a complete graph is assembled. Then once the graph is assembled it would be a case of outputting this in a way that some packaging logic could process (or if you are feeling daring, the JDK has its own built in Jar creating/modifying code to do it yourself). Granted, this approach would require writing this custom utility and would also miss fully qualified class references in the code.