Using the basic-lib Generator
The basic-lib
generator creates a new library with Bitwarden's standard configuration and
structure. It sets up all the necessary files, configurations, and hooks with global configuration
files.
Command Syntax
You can use the basic lib generator by running this command:
npx nx g @bitwarden/nx-plugin:basic-lib
Available Options
All fields are required, but do not need to be supplied as CLI flags. Generator users will be asked interactively for each of these if they are not supplied as CLI flags.
Option | Description | Required | Default |
---|---|---|---|
--name | The name of the library | Yes | - |
--description | A brief description of the library | Yes | none |
--team | The team responsible for the library | Yes | none |
--directory | The directory where the library will be created | Yes | "libs" |
Step-by-Step Example
Let's create a new utility library called "password-insulter":
- Open your terminal and navigate to the root of the Bitwarden clients repository
- Run the generator command:
nx g @bitwarden/nx-plugin:basic-lib --name=password-insulter --description="Like the password strength meter, but more judgemental" --team=tools
- The generator will create the library structure and update necessary configuration files
- The new library is now ready to use
What Gets Generated
The generator creates the following:
-
Library Structure:
libs/password-insulter/
src/
index.ts
- Main entry point
README.md
- With the provided descriptionpackage.json
- Very minimaltsconfig.json
- TypeScript configurationtsconfig.lib.json
- Library-specific TypeScript configurationtsconfig.spec.json
- Test-specific TypeScript configurationjest.config.js
- Test configuration.eslintrc.json
- Linting rules
-
Configuration Updates:
The generator then updates tsconfig.base.json
to reference your new library, updates CODEOWNERS to
assign the team to the new folder, and runs npm i
to link everything up.
Post-Generation Next Steps
After generating your library:
- Review the generated README.md and update it with more detailed information if needed
- Implement your library code in the
src/
directory, using whatever subfolder structure you prefer - Export public APIs through the
src/index.ts
file - Write tests for your library
- Build your library with
npx nx build password-insulter
- Lint your library with
npx nx lint password-insulter
- Test your library with
npx nx test password-insulter
Troubleshooting Common Issues
Issue: Generator fails with path errors
Solution: Ensure you're running the command from the root of the repository.
Issue: TypeScript path mapping not working
Solution: Run nx reset
to clear the Nx cache, then try importing from your library again.
Extending the Generated Code
The generated library provides a basic structure that you can extend:
- Add additional directories for specific features
- Create subdirectories in
src/
for better organization - Modify the Jest configuration for specialized testing needs
Designing a Library
There are a few ways you and your team may want to design a library, there are a lot of factors to take into account like clean organization, ease of onboarding new members, simplicity of moving ownership to a new team, and optimizing for module size. Below are a few ways you might want to design a library.
Option 1: Feature-based libraries
One strategy to employ is a feature-scoped library.
The import for such a library would be @bitwarden/[feature]
. For example the global-state
feature would be imported with @bitwarden/global-state
.
If the feature has both a UI component and needs to be used in the CLI it would probably result in a
@bitwarden/[feature]-ui
or @bitwarden/[feature]-angular
library as well.
With more things being added to the SDK and the CLI eventually being written directly in Rust there will become less and less need to have a package with an Angular dependency and without it.
Pros
- You'll have smaller libraries that have minimal dependencies, making them easier for another team to depend on without a circular reference.
- If your team is ever split or a feature you own is moved to another team this can likely be done
with just an update to the GitHub
CODEOWNERS
file. - You'll have a clearer dependency graph.
- Your modules will be smaller.
Cons
- YOu have to spend the time to think about and define what a feature is.
- You have to create libraries somewhat often.
- You MAY need "glue" libraries still.
- It is not as clear who owns what feature from looking at library names.
A "Glue" library is a library that might not exist other than the need for two teams to collaborate on a cross cutting feature. The glue library might exist to hold an interface that team B is expected to implement but team A will be responsible for consuming. This helps glue 2 features together while still allowing for team A to consume other things that exist in team B's library but still avoid a circular dependency.
Option 2: Team-based libraries
Another strategy would be to have a library for the vast majority of your teams code in a single package.
There are many ways you may choose to design the library, but if it's one library you will need to be dependent on everything that makes all your features tick.
If all teams go this route it will be impossible to only have these team libraries. Why? Because the team grouping is very likely to result in circular dependencies. For example, if team A depends on team B's library then team B cannot depend on anything in team A's library. If team B did need something they would need to request that team A move it "downstream". Team A would need to move their code and come up with a name for it. If they don't want to also re-export those pieces of code they will need to update the import for every other place that code of used. You may also have to deal with the code now being separated from similar code or you may decide to move that code too.
Pros
- You have fewer libraries to maintain.
- All your team’s code is in one place.
Cons
- You'll need to move code ad-hoc more often to make glue libraries, and each time try to think about how to design the package abstraction.
- If your team splits you will need to move a lot more code.
- You’ll have larger modules.
Option 3: Type-based libraries
You can also split libraries based on the primary kind of file that it holds. For example, you could
have a library holding all type
’s, one for abstractions
, and on more services
. Since one
library for all type’s would be mean having a library that has multiple owners it would be highly
discouraged and therefore this would likely be split by team as well, resulting in packages like
@bitwarden/platform-types
; this library strategy is really a subset of the team-based one.
Pros
- You’ll be less likely to have circular dependencies within your team’s code, since generally Types < Abstractions < Services where < means lower level.
- It’s most similar to the organization strategy we’ve had for a while.
Cons
- There is no guarantee that all the types for a given team are lower level than all the types of another team that they need to depend on. Circular dependencies can still happen amongst teams.
- It’s also possible for a type to need to depend on an abstraction,
- We are generally discouraging teams from making abstractions unless needed (link).
Option 4: Feature/type hybrid
Another strategy could be to split libraries by the kind of item in feature-scoped libraries.
Pros
- Lowest chance of circular dependencies showing up later.
- Pretty easy to move ownership.
Cons
- The most libraries to maintain.
- Consumers will likely have to import multiple modules in order to use your feature.
Platform Recommendation
Given the options available with Nx and the pros and cons of each, Platform is planning on using feature-based libraries and we recommend other teams do as well.
We understand that we might have a domain that is a little easier to split into features, but we believe that the work is worthwhile for teams to do.
There will be some instances that our libraries may only contain abstractions and very simple types which would then resemble the type-based approach. We will be forced to do this because we have some things like storage where it’s only really useful which the implementations made in the individual apps.
Example Platform feature libraries (all of these would be imported like @bitwarden/[feature]
:
storage-core
user-state
global-state
state
(will have its own code but also a meta package re-exportinguser-state
andglobal-state
)clipboard
messaging
ipc
config
http
i18n
environments
server-notifications
sync
Hopefully these will give you some ideas for how to split up your own features.
Further Learning
For more information about Nx libraries and generators: