chore: ESM for localization

[chmelevskij]

@McGiverGim I've moved localisation.js to modules. However there is one small caveat is because it's in NWJS.

NWJS exposes require in the UI and allows importing native modules that way. But, it doesn't allow consuming in built node modules through ESM. So, import fs from 'fs' won't work.

I've added a solution where I just replace the import as string, but it's quite unstable. Haven't tried it but if another part of the app is migrated to import/export it will brake I think.

It is quite a unique issue, since usually you either run in browser or in node, this one is a mix.

I could potentially write a rollup plugin for this if it pops up quite often 🤔

[McGiverGim]

I don't understand exactly the implications of this, I need to look at it slowly.
The objective was to fix the Android build. I need to test it.

[chmelevskij]

Android is using cordova. Which is just webview in the app. It doesn't have access to things like filesystem in a way NWjs/node has. So using filesystem loader won't work 😕

I think previous solution with XHR request would be needed. Maybe just change it so that messages with initial load are baked in somewhere and switchign the language would load the new ones async

[McGiverGim]

We removed chrome to have only one coding for all, it seems it will be impossible! Or at least we need to go back and return to old code...
Our code waits to load with a callback, but Vue is not doing it because it does not execute the init method.

[McGiverGim]

One thing more @WalcoFPV said it has included the nw apis to Cordova. So maybe the fs will work but I don't know if it needs some hack to do it.

[WalcoFPV]

One thing more @WalcoFPV said it has included the nw apis to Cordova. So maybe the fs will work but I don't know if it needs some hack to do it.

I included the Chrome apis, not the nw apis. But the node modules should work with Cordova as well. I think, we must separate all the functionnalities depending on Cordova apis and Nwjs apis and create our proper apis. For example, creating an object apis or native with methods like native.serial, native.clipboard, native.filesystem, ... defined for both Cordova and Nwjs with their proper apis, but we will have only one api in the "common" part of the code for Cordova and Nwjs. All the things which should be done differently between Cordova and Nwjs should be done like that I think.

This will not fix the issue with the require function not functioning with Cordova but it will allows us to replace old Chrome apis with Cordova and Nwjs apis in an easy way.

[McGiverGim]

I think this code is a good case to try to get to a final solution. We are using one module as i18next backend that internally uses the node fs api.
Do you think there is an easy solution for this?
We need to search one way to make it work for both systems without hurting too much the developers.

[mikeller]

I think using an API wrapper is the right approach here. Luckily we now only need two implementations of it, for NW.js and Cordova, and not one for Chrome Web apps as well.
Instead of writing our own wrapper, I think we should first see if something suitable is already available, like https://github.com/evanshortiss/html5-fs or https://github.com/LockateMe/cordova-plugin-file-node-like.

[McGiverGim]

I'm not too sure if I'm understanding what kind of wrapper are we talking about:

1. The best approach is to see if there is some wrapper, created by someone else, that we can add and produce a totally transparent use of the Node api in Cordova (at least the fs api, that is the one most used). In this way we can use Node plugins and Node api directly in our code.
2. The second one is to find a wrapper over the filesystem that works for both, Node and Api, but I suppose this will not replace the Node API so the plugins that use the Node API will not work in Cordova. We will need to use other plugins.
3. The wrapper that @WalcoFPV comments I'm not too sure if is the same than 1 or 2, but created by us.

@WalcoFPV you are the only one here with enough knowledge about Cordova. Do you know if 1 is possible? If true, have you time to try to make a working code, starting for example with this PR? Is a good example of what we want. If not possible then we need to pass to option 2, and remove the use of Node plugins.

I think is good that we can use modules, with the approach of this PR or another one if someone knows a better approach, using import if require is not supported by Cordova.

[mikeller]

@McGiverGim: I guess all of the above. :-)

Also, thanks to the open nature of JavaScript, it is possible to polyfill functionality, and have wrappers that transparently replace native functionality, even if it is called from within modules. But having some sort of abstraction layer, and preferrable one not implemented and maintained by us, is the way to go in my opinion.

[mikeller]

I think this is outdated now since we have reverted the change to the fs backend for i18n. What should we do with it?

[McGiverGim]

I'm not too sure, this is s good example that we can need at some moment, but true, at this moment and for this scenario is not needed.

[chmelevskij]

This wasn't really tied to the fs. I'll adapt this one to the current master and will push it this weekend.

It will setup general steps on how to migrate other parts of the app to modules.

[chmelevskij]

Modules are in strict mode by default

[chmelevskij]

strict mode is default mode when using modules.

[chmelevskij]

Adjusted to use xhr backend now and some cordova changes. Also remove some of the script tags, since rollup handles the bundling.

@WalcoFPV or someone with access to android, it would be good to verify that it works. I've only run some smoke tests on android emulator.

[McGiverGim]

If it works in the emulator it must work in the real device. At least a device with the same configuration/versions that the emulator. We can have problem with different devices, but this will happen we test it in an Android or not. Until merged and used by others with different devices we will never be sure, but this will happen with any change we do.

To me is ok, I think is a demo of how to use modules with import in our "new" Configurator. I think is valuable and we can merge it.

[chmelevskij]

Yep, I think this pretty much covers most of the cases.

There will be things likeimport '../js/localization.js'; which have side effects of attaching things to window since a lot of stuff relies on global singletons to work. But eventually we should be able to get rid of these things.

[McGiverGim]

There will be things likeimport '../js/localization.js'; which have side effects of attaching things to window since a lot of stuff relies on global singletons to work. But eventually we should be able to get rid of these things.

Yes, that is probably the worst, because the i18n.getMessage() is widely used across the application.

[McGiverGim]

@chmelevskij one thing more, the tests are failing. I didn't remember the tests... I had the same problem when I tried to do this...
They are configured to be executed in a Chrome browser...
Can you check at them?

[McGiverGim]

Good job! Thanks for fixing this!

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
0 Code Smells

No Coverage information
0.0% Duplication