Nx also provides a linting rule out of the box to make sure that you are respecting a lib’s API and not doing deep imports. /./users/lib/src/index.ts and helps protect us from the overexposure problem described above. When we want to import UserService inside another lib or app, we want to import it from This is way cleaner then importing it from a relative path like. libs/users/src/index.tsĮxport * from './lib/services/rvice' Īlthough this might seem pretty straight forward, let’s go over a few best-practices… Don’t ever import a lib from a relative path This is what the barrel file from might look like. Let’s say that we have a lib which exposes a UserService… The Nx lib’s index.ts file allows each lib to define its effective public API - only symbols which are explicitly exported from this file should be eligible for consumption in other parts of the workspace.
#Will ug nx accept .imp code
With code being located right next to each other, it can be easy to import code with deeply nested relative paths and include things that the original author of the code never intended to be used outside of their specific context. This file is really important when you understand one of the big potential risks of organizing code in monorepos - overexposure of implementation details. When it comes to managing monorepos, barrel files are quite important.Ī barrel file is a index.ts file that lives in the src directory of every Nx lib and is meant to expose logic to the rest of the workspace. Nevertheless, I would love to share how I architect large Angular applications with Nx. Best practices and guidelines are mostly a matter of perception and personal preference.
The rules and guidelines written down in this article might work for you, and should in no circumstances be treated as the ultimate truth. Nx is especially valuable when managing big Angular applications that have a lot of shared functionality, but even in smaller projects it can help organize your approach.Īt StrongBrew we are using this technology for a bunch of our clients and even though Nx is already pretty opinionated, I decided to write down some best practices and guidelines that I try to take in consideration. Nx is actively being developed and updated along with Angular by the amazing people of Nrwl. An app is a deployable unit and a lib is meant to contain the actual logic that can be shared across the workspace. Nx is a thin layer on top of the Angular CLI that helps us with structuring large applications in the form of monorepos.Ī monorepo contains only one Nx workspace that can contain multiple apps and multiple libs (we will refer to apps and libs as Nx projects). That being said, I’ve been using it for a while now, and I finally have the feeling that I’ve reached a structure where I feel comfortable with.
#Will ug nx accept .imp how to
I wrote this article because when I used Nx in the beginning, I struggled a lot with how to structure my workspace, and I’ve hit quite a few walls. This article contains a set of opinionated guidelines when it comes to building monorepos with Nx. Opinionated guidelines for large nx angular projects Brecht Billiet
0 kommentar(er)
