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

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 …

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 4
Comments: 15 (2 by maintainers)

Most upvoted comments

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.

NathanWalker on Feb 23, 2021

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 .

NathanaelA on Feb 17, 2024

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.

edusperoni on Feb 26, 2021