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?
Related
Is there a possibility disable SAP Spartacus I18next module in order to use my own translation module/strategy?
I'm trying to use my own shared module with translations but it is based on i18next library same as inspartacus/core, it seems like they are conflicting, because separately they work good.
It is possible but it would require a lot of work. I18nModule is a core part of the project and is imported in the StorefrontFoundationModule that is used in the in the StoreFrontModule and so on.
Therefore, to remove it would require to import all of the modules imported in the StorefrontFoundationModule, StoreFrontModule and B2cStorefrontModule. Directly to your AppModule. This is doable but the app is likely not to work.
Many components and services depend on translations so you would need to make sure your custom translation is provided in a way that it satisfies those dependencies.
Basically I am saying you are better of trying to extend or override the Spartacus translation functionalities to fit your use case. This module is configurable, extendable and powerful. Feel free too take a look at our documentation on the subject https://sap.github.io/cloud-commerce-spartacus-storefront-docs/i18n/#page-title.
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?
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.
Some pyx files require advanced cython features. Some are not. Thus different pyx files have different minimum cython version requirement. Is there any mechanism that we can tell cythonize to throw an error if the version does not meet the requirement when it processing a pyx file?
We have many pyx files we would like to reuse. Use centralized way to manage the version requirement is clumsy obviously.
The recommendation is to generate the C files with Cython once, with an appropriate Cython version, then commit and reuse those C files for compilation without re-cythonizing.
That way, the version of Cython used is static and so are the resulting static C files which then do not need Cython installed.
Even with a minimum version specified, there is no guarantee that a later version of Cython will produce the same C code, or that the later version will work as expected.
From documentation:
It is strongly recommended that you distribute the generated .c files as well as your Cython sources, so that users can install your module without needing to have Cython available.
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.