Become a member
to unlock all features

Level Up!

Access all courses & lessons on egghead today and lock-in your price for life.


    Share a lib in an Nx Workspace with a web and NativeScript app


    In this lesson we will look at how to setup an Nx workspace to allow libs to be shared with a NativeScript app. Considerations for tsconfig, livereload and testing will be looked at.



    Become a Member to view code

    You must be a Pro Member to view code

    Access all courses and lessons, track your progress, gain confidence and expertise.

    Become a Member
    and unlock code for this lesson
    orLog In




    Instructor: Let's share some code between a Web and mobile app. From the root of the workspace, we can do ngg app, and we'll call this Web. While we're at it, we're also going to generate a lib called common. This will be an NgModule. We'll see we now have this common module, and we have our mobile and Web app here.

    Let's create a new pipe. We'll call it age-from-date, and I'm going to drop this in. This is a pipe that takes the date, and calculates what the age of a person might be from that given date. Let's make sure our common module declares that, and also exports that.

    You can see, obviously, the common module is already taken by Angular's common barrel. You want to be sure that you take that into consideration when you create shared libs. In this case, we're going to call it common-egghead-module, and move on.

    We can now use this shared module inside of our mobile and Web app. If we go inside the NativeScript app, there's a shared module already set up. We want to include this additional shared module.

    The name space is going to be the name of the mono repo that we created for the NX workspace. In this case, it's Egghead, and our lib is called common. This will give us access to the common-egghead module.

    As you can see, we're not getting Intellisense, and the NativeScript app is not picking this up by default. There's a couple of extra things we need to do to make sure we can share these libs with NativeScript.

    It starts with adding a simple package to our shared lib here. All this package needs is a name, and in this case, it's egghead-common. We'll give it a version for good measure, then we'll specify our main to-point-to index. We will also specify a typings, and in this case, it's going to build a default declaration for the index.

    Now, what we can do is go into the mobile app. We're going to install it just like in the other dependency. This time, we're going to go back to libs and common. We'll make sure that's saved.

    Now, when we look back at our shared module, we can see it does see the common-egghead module, and we'll add it to the shared modules array here, which imports and exports that same collection, and makes those pipes, or components, or directives available to the entire NativeScript app. Let's now do the same for Web.

    In this case, we're going to import it into our app module, and we'll add it to our imports. Let's put it to use, and see if it works. The pipe that we created is called age-from-date. In our Web app, we're going to add an age-1 here, and we'll use it. We'll create a birthday variable in the component that we'll use our age from date pipe on. Let's create that now. I'll use my actual birthday.

    Let's set up something similar in our mobile app now. For simplicity, we'll add this on the action bar that is attached to the top of our first item list here. Inside this title property, we'll bind it, and use our age-from-date pipe.

    This will be another birthday property we'll add, that will go to our age-from-date pipe. We'll set up the birthday, and we'll use the same thing, my birthday, here. Before we run this, it sure would be nice to get the same lively load effect that you get with Web development when you make changes in your shared libs or in your Web code. We'd love that same behavior for our mobile app.

    We can do that by adding just an extra script here on our root package. We'll add one called start.ios, which is going to change into the mobile app directory, and run tns-run-ios in the emulator for development.

    We'll pass the special sync all files flag. This option is what's going to allow us to live dev against our shared libs. We could expand further to add a convenience script for Android as well.

    Before we start to run the mobile app, let's see if our Web app actually works. You'll notice this error if run right away. This is because we need to exclude the app's mobile directory, since it's NativeScript-specific.

    We'll add apps mobile to exclude on our app tsconfig, and it will run now. For good measure, we're going to do the same thing across all the tsconfigs that the NX workspace had set up for us. We'll also exclude it here. Now, we can see the Angular CLI Web app runs fine, and our age pipe is working. I am 37 years old.

    We're going to leave the Web app working for now, and open a new terminal. We're going to run our iOS NativeScript app in this terminal. We can see the app launch, and we see the same I am 37 in the action bar title bound, just like we did in our Web app back here.

    I have a live development environment for iOS going, and a live development going for Web. Let's make a change to our shared lib. We'll just add the words years old to the end. We can see the Web app updated, and our iOS NativeScript app, because they are both sharing the same Angular pipe.

    As a note, I would not recommend running live development against Web and iOS at the same time, just live develop against one or the other.

    Lastly, if we were to run npm test against our entire repo right now, you would see this error. This is because it's trying to pick up a ts file that is inside the platforms directory in our NativeScript app. You want to avoid this.

    Let's make a small change to our actual testing config in the test.js. We're going to add some regex here that uses a look behind to exclude the platforms or the tns modules directory that sometimes gets added to the app directory during build. This will ensure that our unit tests still run.