I'm trying to conditionally import device-specific ES6 modules at run-time using Rollup and either Babel or Buble. I've seen similar questions but am still unclear if this is possible.
I've used Rollup since it's easy to generate UMD and ESM modules, then using the module/nomodule script pattern to ensure each device uses the appropriate module.
Is this possible yet with Rollup? Is there an alternative approach using a module loader that can determine whether to import ES5 or ES6 at run-time, or should I revert to Webpack?
Related
This declares an ES6 module:
<script type="module" src="animals.js"></script>
My problem is: this makes a 1-to-1 connection between a module and a source file.
I would like to split "animals.js" into "dogs.js" and "cats.js". Is this possible with ES6 modules?
I would like to define the module in this way:
<script type="module" name="animals" src="dogs.js" src="cat.js"></script>
ES modules are constraint to a single exporting context which happens to correlate to a single automatically created exporting context per file. So you can’t. You can however introduce a new module and it will be its own file/script block.
Alternatively, you can use a bundler that will accept several input files and produce a single ES module output file. Webpack might be a great choice.
Alternatively, you can introduce a module that imports and exports the contents of the other modules, serving as a kind of a wrapper or facade if you will.
Also, keep in mind that 1-to-1 connection between a script file and an ES module is inherent to the whole design of the ES modules, as well as many other bundling and namespacing systems. This is legitimately a feature and the need to have more than one source file per module might designate a flawed architectural design in your software.
If you would like a Java-like module behavior, you should definitely check out Typescript namespaces. Although, you will eventually realize how many different type inference caveats and parallel module visibility issues are there and thus will stop using them altogether in favor of ES2015 modules, they might be useful for just getting used to the modern technology.
I'm using VB/.NET through Wonderware's ArchestraIDE Quickscript.net scripting language. I see there's quite a few ways to deal with JSON deserialization in .NET (DataContractJsonSerializer, JavaScriptSerializer, Json.net/Newtonsoft.Json) - but can't find any in the Wonderware subset.
It seems like JavaScriptSerializer isn't included as part of the .NET framework for Quickscript.NET, as ArchestrA doesn't recognise anything from System.Web.Script; and neither is DataContractJsonSerializer (System.Runtime.Serialization.Json isn't there).
I didn't find anything about json in the Quickscript.net docs either.
What is the standard/best way to deserialize JSON in this environment?
I'd recommend you to work on an external program to test JSON deserialization as a Stand-Alone method (using some third party libraries like Newtonsoft .NET) to compile it into a DLL. Then later import it to ArchestrA framework via the IDE and use your own method.
It will be a better approach since that with ArchestrA scripting you won't be able to declare classes or use listings, which are some things you should do when dealing with nice structured JSON deserialization for your better understanding.
Here's the catch, avoid compiling a code library that makes external reference to another one. ArchestrA's objects can't handle that external call in runtime, even if you import the other library and all other dependencies. There is a way to properly import a DLL that depends on other libraries to execute, but it's not the best practice in my opinion if you (or other unadvised person) are going to do future maintenance in your source code.
My final recommendation is to get the source code of open libraries (like Newtonsoft .NET), and make your program as a class alongside its project, and compile it into a single build. After that, you'll just need to import the library and do the proper method calls and classes instances.
If you prefer not to use a single compilation project, try to use ILMerge to merge the two libraries into one, even if they have a dependency, it works on ArchestrA objects at runtime.
I use newtonsoft .net library by importing it into the Wonderware IDE (Galaxy>Import>Script Function Library)
https://www.newtonsoft.com/json
I'm using Babel with default es2015 preset to convert ES6 JS code. Since I'm working in another project with TypeScript, I've come to appreciate the publi/private annotation on methods.
I'd like to use the same annotation in JS code. Even if it won't actually make methods on the exported object private, I find it useful to know quickly if a method is used by other classes, or not.
Is there a Babel plugin or other means to strip away all public/private declarations, so I can use it in my code? even without namespace checking that would still be very helpful.
There is a current proposal for "Private Fields" that is in the process of being implemented, but it not part of Babel yet. In the next month or two I'd expect it to be available.
Disclaimer: this is a hypothetical scenario.
Suppose I have two ES6 modules, module-a which depends on momentjs#1.x and module-b which depends on momentjs#2.x.
How do I structure the SystemJS / JSPM configuration and the module import statements such that module-a gets momentjs#1.x and module-b gets momentjs#2.x?
I am building a module that exports a cmdlet that I would like to make available through my profile. The implementation of this cmdlet is spread across multiple implementation files that contain implementation functions I don't want to make publicly available. So I use Export-ModuleMember to hide them.
File get_something.psm1
import-module .\get_something_impl.psm1
function Get-Something {
[cmdletbinding()]
Get-SomethingImplementation
}
Export-ModuleMember -Function Get-Something
I then add get_something.psm1 to my profile. By exporting only Get-Something, all of my implementation functions remain "private".
The issue I'm experiencing is that when using the Export-ModuleMember command, I have to import a module in my implementation files every time I need a function inside of it. For example, assume I have a module, person.psm1, with a function, Get-Person, that I need to call throughout all of my implementation files. Now I must import person.psm1 in every single file that I need to call Get-Person. This is a result of using Export-ModuleMember-Function Get-Something. Without it, I would only need to import person.psm1 once and it would be available.
In essence, Export-ModuleMember is not only blocking my implementation to the outside. It's blocking it from my own implementation.
Is this expected and considered a normal aspect of designing PowerShell modules?
This was actually a bit of debate during the development of modules. Originally, Export-ModuleMember was required to export any function. This became tedious and limiting. So, by default, all functions from a module are visible, but variables and aliases are not, as long as you've never used Export-ModuleMember within the .PSM1.
If you use Export-ModuleMember, it begins to restrict that list. It may not be a bad idea to export a smaller number of functions, but you have to use it somewhat carefully.
You can either write:
Export-ModuleMember -Function a,b,c
which exports a few functions.
or
Export-ModuleMember -Function *
The latter one is equivalent to omitting Export-ModuleMember altogether.
You can use more restrictive wildcards if you'd like, but I find that 99% of the time, you don't need to bother with it at all.
The other thing you seem to be asking is how best to handle module dependencies. Nowadays, it's fairly common to import a module or two when writing a script, just like it's fairly common to include an assembly or two in a C# project. If you're doing this inside of a module, you can use the -Global flag on Import-Module, and avoid using -Force (which will reload the module). This makes it a notch more efficient to reuse the module in different functions. It also makes it less likely to have problems with "cycling" (unloading and reloading) the module, which, unfortunately, many modules do not do well.
The alternative to referencing the module in each function is using a module manifest (Get-Help New-ModuleManifest). Module manifests are very interesting, and required learning for many parts of module development. If you include a module in the RequiredModules list of the Module manifest, it will be automatically loaded before the module is imported (at least in PowerShell 3 and greater). If you include a module in the NestedModules list of the module manifest, it will be loaded as part of the module, and the commands exported by the module will be exported by your module instead.
Module design is a tricky beast, but it's very rewarding to do right. Best of luck.