Check out the command line reference for detailed usage information.
Problematic or failed replacements are reported in the log. Consider the following tips when migrating your codebase.
Every change generated by ui5-migration should be inspected by a human, as there might be problems which can not be solved automatically:
The tool tries not to overwrite existing variable names. Therefore it adds a counter to the name in order to make it unique.
Sometimes this is due to a shortcut in the old code e.g. var log = jQuery.sap.log which creates a conflict when introducing the argument log.
Even though this shortcut isn't needed anymore, the tool does not remove the variable and thus a rather useless shortcut like var log = log0 remains.
Sometimes there are @see or @link references to the old modules, for instance jquery.sap.log. These are not changed, as comments need to be adjusted manually.
Even though the functionality shouldn't break after migration (at least with the replaceGlobals module), it is not guaranteed to generate eslint-compliant code. Especially more complex rules like nested ternary expressions or extra binds might be violated.
You might have some modules with comments in the sap.ui.define call, e.g.
], function(
Device,
Control,
ShellLayoutRenderer
/* , jQueryDom, jQueryScript */,
containsOrEquals
) {The corresponding dependencies might not exist, or are in different order, so you would have to modify these comments accordingly.
ui5-migration tries to make the diff between the original source code and the modified one as small as possible while trying to stick to the original source code style. Sometime this fails and the modified code might need some reformatting.