Nativescript-angular: Code Sharing project build fails since Angular 10 and NativeScript 7

[jessorlisa]

Environment

• CLI: 7.0.10
• Cross-platform modules: 7.0.10
• Android Runtime: 7.0.0
• iOS Runtime:-
• Plugin(s):

- @nativescript/secure-storage: 3.0.0
- @nativescript/theme: 3.0.0
- nativescript-ui-sidedrawer: 9.0.3

• NativeScript-Angular: 10.1.5
• Angular: 10.1.4

Describe the bug
This issue refers only to Code Sharing projects
Since the upgrade from Angular 8 to 10 and NativeScript 6 to 7 npx rimraf hooks node_modules platforms && npm ci && npm run android fails with errors like:

ERROR in src/app/pages/app/app.component.html:2:30 - error TS2339: Property 'lockSideDrawer' does not exist on type 'AppComponent'.

2     <mat-toolbar-row *ngIf="!lockSideDrawer">
                               ~~~~~~~~~~~~~~

  src/app/pages/app/app.component.tns.ts:20:18

lockSideDrawer in this example exists both in

• app.component.ts
• app.component.html

but not in the .tns.* files:

• app.component.tns.ts
• app.component.tns.html

In code sharing projects any *.html template file should be ignored if there is a matching *.tns.html file. Only NativeScript files should be considered.

This worked totally fine with Angular 8 and NativeScript 6.

More details on Code Sharing projects: https://v6.docs.nativescript.org/angular/code-sharing/intro

The strange thing: Another npm run android afterwards builds successfully. But any live code change in any component produces the same error as above.

Assumption: Code Sharing projects are not fully supported with NativeScript 7, or is there anything I am missing?

To Reproduce

• Setup sample project (see below)
• npx rimraf hooks node_modules platforms && npm ci && npm run android

Expected behavior
Build succeeds without errors

Sample project
Edit: sample project deleted ...

[plackowski]

I have the same errors. It's a bad that this bug exists since 29 days for now :/ Next example that code sharing between ns and ng was a bad idea..

[Heena-Vora]

Same issue for longer time now

[MohammedrezaFouladi]

same error after migrating my code shared project to NS7

[MohammedrezaFouladi]

I fixed the issue in 3 steps:
1 - separate web and native routes to app-routing.module.ts and app-routing.module.tns.ts. Clear routes in
app.routes.ts like => export const routes: Routes = [];
remove routes imports from app-routing files and use(export const routes: Routes = [];) to define your web and native routes
2- make two component class files, one ts file for web and one tns.ts file for native
3- change templateUrl of tns.ts file to tns.html

[jessorlisa]

@MohammedrezaFouladi Thanks for sharing, but for me that sounds as a workaround and not a fix. Anyway it will hopefully help anyone proceeding with their projects and upgrade process for now.

But: It makes the whole "code sharing concept" useless. I have a similar approach for the time being. But one of the main reasons we decided to go with NativeScript and Angular was the code sharing capability, which is sadly no longer working since NS7/Angular 10. I really hope this will be fixed properly.

[kingjordan]

I had the same type of errors, the issue was that I had imports that were incorrect in a couple components. I had to make sure to convert all of the imports to @src/app/...

I found these errors after I tried to add nativescript to an existing angular 10 web app. The weird thing was that vs code did not detect any of these import errors. I had to search for them and open each component.ts file in my project to verify. Once I fixed them all the build and other cli tasks worked again.

[jessorlisa]

@kingjordan Thanks for the hint, however all imports are scoped imports (see sample project). The issue lies elsewhere here.

[lostation]

Any news on that ? I'm facing same issue...
I wonder if shared mode is still functionnal... In my codebase I've a lot of Components with or without tns extension and it was perfectly building and working with NS6 👌... Since upgrade to NS7 I'm in real troubles with huge template parsing error amount... I reduced the error amount with fulfilling excludes array from tsconfig.tns.ts with not used files in nativescript part of app but it's not enough 😔... And I'm not even sure that adding stub tns extension file will be working as before... I suppose it's too soon to really go to ns7... So sad... Hope fixes will come soon...

[lostation]

Hi there,

* Updated infos on this issue *

I've sent an email to the team core members (nsStudio)... And it seems this issue will be an long story issue...as it exists from Oct 2020... 4 months without solution to fix this serious breaking change !!! :-( ...And with the answer I got...
I don't think they will do any fix about it... 👎

They say to me that using shared mode like I always did ( so based from NS6 online docs ... ) won't work anymore ( shared mode removed intentionally or not from NS7 update ???... It's not clear to me ...) and they prefer to manage theirs shared projects with a tool named NPX workspace stuffs... -> How NPX can helping me out with that issue ? It creates several sub projects ? Is that ?Then it's not shared anymore...I don't understand... My project is a three years old big angular truck so I cannot refactor everything only for that...I'm not the only one working on that project. It will be overkilled time consuming...

They've also tell me that if I want a fix for that issue, I should pay for a contract support with nStudio and then, they will helping me out... I obviously have not any problem to pay for a custom code implementation work or any new custom component or whatever that I cannot do myself ... but here... We are talking about solving a framework breaking change issue introduced with NS7...

I'd really like more infos on that from the core members !!!
Has the shared mode been removed ? Or it's just a bug ? Or what ? Alternatives ?

So... Is there any other ideas like @MohammedrezaFouladi has already proposed ?
Cause I think that's effectively a kind of workaround (I didn't tried it yet until now)...
But if it works and in the future any fix will popup ... I will re-do the reverse work...Pffff

-> Maybe the way to go is to add another webpack file replacement mechanism for all the files tree... don't know...

Cheers.

[NathanWalker]

Long story short. Code sharing is always supported with NativeScript in a wide array of approaches. One such approach is one that the prior core team put forward with @nativescript/schematics.

Many in community including ourselves are opposed to that approach. It's overly heavy handed with configuration details that are unnecessary and also not scalable in a sense that is meaningful for code sharing at the heart of what you really need over time with code sharing to scale and maintain for years into the future.

This has been the case for quite a long time and we have stated this repeatedly.

We (nstudio) built xplat for the purpose of code sharing effectively with scalability at the forefront. This scalability goes beyond just NativeScript and web, but also allows mixture of other platform combos. It's based on Nrwl's Nx which in and of itself is infinitely scalable in the code sharing space.

xplat has been available for as long as @nativescript/schematics and we are honestly sad that people out there have gone down the @nativescript/schematics path as it leads to numerous issues as stated above. Those schematics require more maintenance work due to fact they took a heavy handed approach to configuration.

We maintain xplat, use it everyday, multiple times a day. We have a hard time standing behind @nativescript/schematics as we would not have recommended in the past and don't recommend it now.

Now that we maintain NativeScript itself, we are left with a difficult decision deciding should we close @nativescript/schematics and remove from the docs. We know people out there have used it with success however it's a short sighted success as you have seen above. it leads to problems in maintenance with community updates, so on and so forth.

Code sharing is always supported with NativeScript, it's just the approach you use to do it. We support xplat for that purpose and more importantly Nrwl's Nx as the appropriate vehicle to do it.

If someone out there wants to maintain @nativescript/schematics as a bonifide code sharing direction, NativeScript is open source and available to be involved with it's development at anytime.

We currently have no TSC (Technical Steering Committee) members that use that technique for code sharing. We would Love other companies and people to join the TSC and help maintain the parts they use so let us know if you're interested in that.

[lostation]

Hi Nathan, really thanks for your answer and reaction...

As you said you and all core team are now maintaining nativescript and that's great !

So you have accepted to maintain the project then this kind of issue is also called a technical debt...and it's your responsability to live with it.

A lot of people (including me) have choosen ns for that feature and were building projects based on the way it was described on ns docs... Telling us we did it the wrong way is not really a good reason.

My point of view, actually, you cannot refuse to abandon and close a complete killer feature just because you have decided it at one moment without thinking of all consequences for a lot of people.

If for you it's so a wrong way or too heavy to adjust or update for NS7, OK I can understand it, no prob, but just make it happened differently and progressively, first prepare all your user community with communications and set all of this as deprecated and please update the docs with description, how-to-do and alternatives... Once the deadline will arrive, you will remove it without crashing your user's projets 👌...

Sorry but introducing voluntary breaking changes without proposing complete guidelines is not really fair for some of us.

Can you explain a bit more why the ns schematics is now an issue for version 7 ?

Can you also telling me what is now considered as a shared ns web angular project for you ? Small complete and updated demo app ?

When the docs for ns 7 will be available from website ?

Thanks for your help.
Lo.

[NathanaelA]

So you have accepted to maintain the project then this kind of issue is also called a technical debt...and it's your responsability to live with it.

Or just eliminate it, most developers I know want to eliminate any and all technical debt. ;-)

A lot of people (including me) have choosen ns for that feature and were building projects based on the way it was described on ns docs... Telling us we did it the wrong way is not really a good reason.

We don't disagree that the docs were pointing to one direction, we had no control over the docs until very late in NS 6's life cycle and then we were busy trying to get other things moving in the right direction with the code base that we did drop the ball on the docs. The docs are being worked on, it's not an "easy lift".

But that doesn't change the reality that nobody on the TSC uses @nativescript/schematics. The best way for us to maintain any parts of the project is to actually use the functionality in a day to day usage. (i.e. dog-fooding it). If you would like to maintain schematics, we would love to add more people to the TSC that actually use any functionality (not just @nativescript/schematics). We would love more people in the community on the TSC for any parts of the NativeScript project.

Finally, this is a open source framework, this means you as a user of the framework can help us by creating PR's to fix issues you find, we would gladly take fixes that make @nativescript/schematic work properly again. If you can't spend the time to help create PR's the other way is you can is to purchase support contracts. We use them to help fund the work on the framework, and so then you can file paid support bugs against the @nativescript/schematics.

---

Can you explain a bit more why the ns schematics is now an issue for version 7 ?

Sorry, I don't really know the answer to that, Since we don't use it, we haven't investigated any issues that you may have ran into. We are looking for people who want to maintain it...

Can you also telling me what is now considered as a shared ns web angular project for you ? Small complete and updated demo app ?

See the Xplat repo and docs. (https://nstudio.io/xplat, https://github.com/nstudio/xplat)

When the docs for ns 7 will be available from website ?

NS 7 docs are already up. However, I do not believe we have removed any @nativescript/schematic stuff as we are hoping someone from the community would want to step up and help maintain them. NS 7 docs update was mainly just to update some of the new features and calling conventions) -- we are currently working on many other updates to the docs and if we get no takers from the community by NS 8, the @nativescript/schematics will be removed from the NS 8 docs .

[lostation]

Is the issue is really from ns schematics ? I thought it was for scaffolding angular files...

So OK if I can find some time, I will try to find where the file .tns.ts and .ts discrimination is done... Maybe you can point me to the right direction ?

Also about xplat... I dont think it's an alternative for my case.

If you confirm it, the best solution should be to separate and use dedicated root folders for Web files and ns files...

Is the discrimination of suffixe tns is still working ? Cause finally the principal issue seems occuring only during template files discrimination and not for logical Components and services.

Anyway... Cheers 🍹

[edusperoni]

The end suffix is replaced on webpack by passing the filereplacements to the angular compiler. I believe this isn't exposed in the webpack config but on the ns angular webpack files. IIRC the new AngularCompiler in the webpack config returns a compiler with the replacements already in place. I'm on mobile right now, so I can't point to which specific file, but if you ctrl+click the require it should put it right where the replacement is configured.

[jessorlisa]

@NathanWalker @NathanaelA Thanks for the insights. 👍🏻