Broken apps using 5.4 and LegacyMode=false

[NathanaelA]

Not sure if this is something to be posted here or the webpack issues...

Environment
Created a brand new test app today; latest of everything..

• CLI: 5.4
• Cross-platform modules: 5.4
• Android Runtime: 5.4
• iOS Runtime: 5.4
• Plugin(s): (none extra)
• Webpack 0.22

Describe the bug
If you set "useLegacyWorkflow": false everything works great
If you set "useLegacyWorkflow": true most of the app is broken...

To Reproduce
Happens on both iOS and Android.
You can download my repo from: https://github.com/NathanaelA/event-order and build with Webpack disabled; and you should see something like this when you click the "Navigate" button.

JS: ----------------------------------
JS: Starting navigation to aa-page
JS: aa-Page actually loaded and parsed by JavaScript Engine
JS: NavigatingFrom main-page
JS: NavigatingTo aa-page
JS: loaded aa-page
JS: layoutChanged aa-page
JS: unloaded main-page
JS: NavigatedFrom main-page
JS: NavigatedTo aa-page

Delete your platforms, delete app off of phone/emulator, disable LegacyMode and try it again and you will see this:

----------------------------------
JS: Starting navigation to aa-page
JS: NavigatingFrom main-page
JS: unloaded main-page
JS: NavigatedFrom main-page

First of all you will see NONE of the aa-page events are wired up. AND on the AA-page; the navigate button is disabled (so it also didn't wire up).

Please note Android is easier to test than iOS as I don't have a close button (yet) on the showmodal call; the ShowModal button is also likewise broken..

Expected behavior
Things to work in a Webpacked app. 😀

Sample project
https://github.com/NathanaelA/event-order

[NathanaelA]

The code base has been updated so it has a close button. 😀

In addition it seems like any plain JS app created from the Hello world template has these issues; the two brand new test apps I've done since this bug report have also failed to work with HMR enabled; and worked immediately when I enabled legacy mode...

[NathanaelA]

In addition I have also created a quick NS-Core TypeScript app today; just to see if it had the same issue
CLI: 5.4.0
Android runtime: 5.4.0
Webpack 0.24.0 & nativescript-dev-webpack@0.25.0-next-2019-05-31-150933-01

And it also failed in the same way. Not sure why this isn't listed as a critical bug, none of my NS-Core apps, and even the simple test apps all fail to run properly under the new (soon to be only) method @rosen-vladimirov. I cannot run any apps with more than a single screen if they are a NS-Core apps.

[NathanaelA]

One other comment - you have this tagged as run. I also tried doing a tns build android, deleting the app off the device. Manually installing the newly created apk. And it has the same issue. So it isn't just run. The whole TS/JS app is broken when using webpack..

[PeterStaev]

I was able to find the problem with the Nathanael's app above. The thing about webpack is that it is very picky with modules. So for webpack /a-module and a-module are two different things. The current implementation for the NS webpack registers pages without a slash in front. In the demo above the navigation (and modal open) is done like this:

frame.topmost().navigate("/"+navigationPage);
frame.topmost().currentPage.showModal("/modal-page", {closeCallback: close});

Although the XML loads fine the JS module that should be bound for all the events is not found because there are no such modules. So it fails silently w/o logging anything in the console and works as if there is no JS file for the XML. Simply removing / from the navigation paths fixes the problem and the app works as expected.

[NathanaelA]

Thanks @PeterStaev - That does seem to solve the issue! Tested two different apps. 😀

However, all NS-Core apps from the dawn of time have required you to do .navigate("/pages/somename/some-page") where it starts with a / when you navigate from say /pages/login/login-page otherwise it tries to do a relative load from /pages/login/pages/somename/some-page

So this is a webpack bug; but one that can be worked around... It is interesting that the XML is loaded correctly with the "/" as the first character; but that the attached JS is not properly...

[PeterStaev]

@NathanaelA , actually this was changed at some point. Can't say when exactly but currently it does not look relatively at the path you send. You can move the aa-page in a separate folder and see for yourself.

I can say for sure that since NS 4.2 the navigate() does not consider the path to be relative as I have 2 production apps that we used this approach to develop using standard workflow and on production they are compiled with Webpack. And the navigate paths are w/o a leading slash in both cases and work perfectly fine.

[NathanaelA]

@PeterStaev - Very interesting, well that at least makes things a lot better. So I can convert and be safe... :)

[NathanaelA]

I want to follow up; @PeterStaev is 100% correct -- I modified the app to eliminate the leading "/" and have since that point created another one adding many screens and used the new workflow and everything worked great. 👍

So basically this is a breaking change for people who have been using NS forever; but it is something that can be unlearned, so might just be documented rather than having to be fixed. It is a trivial change in any code base and a change that apparently has worked in legacy mode for at least a couple versions, so it won't break code bases...

Unless the NativeScript team disagrees, this probably just should be documented in the 6.0 upgrade notes and closed...

[rosen-vladimirov]

Hey @NathanaelA , @PeterStaev ,
Thank you guys for the investigation. We are a little bit behind with investigating these issues and such help is really appreciated. As @NathanaelA suggested, we'll probably stick to documenting this behavior.
Thanks again for your time, you are awesome!

[vakrilov]

Hey folks,
As part of NativeScript/NativeScript#7386 we have add a logic that sanitizes module names and should handle cases when the module starts with "\" or "~\". This should make the above paths back-compatible.

About better logging when something fails - we have small improvements in this area too, although I'm sure more can be done.