Building a Single Vue App with Nx

In this tutorial you'll learn how to use Vue with Nx in a "standalone" (non-monorepo) setup. Not to be confused with the "Vue Standalone API", a standalone project in Nx is a non-monorepo setup where you have a single application at the root level.

What are you going to learn?

• how to add Nx to a Vue project
• how to run a single task (i.e. serve your app) or run multiple tasks in parallel
• how to leverage code generators to scaffold components
• how to modularize your codebase and impose architectural constraints for better maintainability

We'll start out this tutorial using Nx together with a Vue application generated with the default npm create vue command. Later, we'll add the @nx/vue plugin to show the nice enhancements that it can provide. Visit our "Why Nx" page to learn more about plugins and what role they play in the Nx architecture.

Final Code

Here's the source code of the final result for this tutorial.

Creating a new Vue App

Create a new Vue application with the following command:

Once you have run npm install, set up Git with the following commands:

This command sets up a Vue app that uses Typescript and is configured to use the Vue router, Vitest for unit tests, Playwright for e2e tests and ESLint and Prettier for formatting. Your repository should now have the following structure:

The setup includes..

• a new Vue application at the root of the Nx workspace (src)
• a Playwright based set of e2e tests (e2e/)
• Prettier preconfigured
• ESLint preconfigured
• Vitest preconfigured

You can build the application with the following command:

Add Nx

Nx offers many features, but at its core, it is a task runner. Out of the box, it can:

• cache your tasks
• ensure those tasks are run in the correct order

After the initial set up, you can incrementally add on other features that would be helpful in your organization.

To enable Nx in your repository, run a single command:

This command will download the latest version of Nx and help set up your repository to take advantage of it.

First, the script will propose installing some plugins based on the packages that are being used in your repository.

• Leave the plugins deselected so that we can explore what Nx provides without any plugins.

Second, the script asks a series of questions to help set up caching for you.

• Which scripts are cacheable? - Choose test:e2e, build-only, type-check and lint
• Does the "test:e2e" script create any outputs? - Enter playwright-report
• Does the "build-only" script create any outputs? - Enter dist
• Does the "type-check" script create any outputs? - Enter nothing
• Does the "lint" script create any outputs? - Enter nothing
• Would you like remote caching to make your build faster? - Choose Skip for now.

We'll enable Nx Cloud and add remote caching later in the tutorial.

Caching Pre-configured

Nx has been configured to run your npm scripts as Nx tasks. You can run a single task like this:

During the init script, Nx also configured caching for these tasks. You can see in the nx.json file that the scripts we identified as cacheable have the cache property set to true and the build-only target specifies that its output goes to the project's dist folder.

Try running type-check for the vue-app app a second time:

The first time nx type-check was run, it took about 2 seconds - just like running npm run type-check. But the second time you run nx type-check, it completes instantly and displays this message:

You can see the same caching behavior working when you run npx nx lint.

Create a Task Pipeline

If you look at the build script in package.json, you'll notice that it is actually doing two things. It runs the type-check script and, in parallel, runs the build-only script.

Instead of deciding ahead of time whether tasks need to be run in parallel or series, let's define the dependencies between tasks and then allow Nx to run them in the most efficient way possible. Update the package.json file with the following information:

Since the build command itself doesn't do anything, we can replace it with an echo to the console. The dependencies between the tasks we can define in the dependsOn property in the nx.json file:

Whenever Nx runs the build task, it knows that the type-check and build-only tasks need to be run first. However, if the build script is run without using Nx (say with npm run build), the task dependencies will not be run. That's why we add the nx exec -- command at the beginning of the build script in package.json. If you run npm run build, Nx will be used to run the task and any dependencies will be invoked correctly.

Now if you run nx build vue-app, Nx will run type-check and build-only first.

There's still one piece of functionality that was lost by this change. The {@} syntax in the original build script was used to forward command line arguments to the build-only script. To accomplish the same thing with Nx, instead of using a string for the build-only task dependency, we'll use an object and tell Nx to forward arguments on to that task.

If you run nx build vue-app -l=error, Nx will run the build-only script with a log level of error.

And once again, running npx nx build or npm run build twice will complete instantly.

Use Nx Plugins to Enhance Vite Tasks with Caching

You may remember that we defined the outputs property in nx.json when we were answering questions in the nx init script. The value is currently hard-coded so that if you change the output path in your vite.config.ts, you have to remember to also change the outputs array in the build task configuration. This is where plugins can help. Plugins enable better integration with specific tools. The @nx/vite plugin can understand the vite.config.ts file and automatically create and configure tasks based on the settings in that file.

Nx plugins can:

• automatically configure caching for you, including inputs and outputs based on the underlying tooling configuration
• create tasks for a project using the tooling configuration files
• provide code generators to help scaffold out projects
• automatically keep the tooling versions and configuration files up to date

For this tutorial, we'll just focus on the automatic caching configuration.

First, let's delete the outputs array for the build-only task in nx.json so that we don't override the inferred values from the plugin. Your nx.json should look like this:

Now let's add the @nx/vite plugin:

The nx add command installs the version of the plugin that matches your repo's Nx version and runs that plugin's initialization script. For @nx/vite, the initialization script registers the plugin in the plugins array of nx.json and updates any package.json scripts that execute Vite related tasks. Open the project details view for the vue-app app and look at the vite:build task.

If you hover over the settings for the vite:build task, you can see where those settings come from. The inputs and outputs are defined by the @nx/vite plugin from the vite.config.ts file where as the dependsOn property we set earlier in the tutorial is set in the targetDefaults in the nx.json file.

Now let's change where the vite:build results are output to in the vite.config.ts file.

Now if you look at project details view again, you'll see that the outputs property for Nx's caching has been updated to stay in sync with the setting in the vite.config.ts file.

You can also add the @nx/eslint plugin to see how it infers lint tasks based on the ESLint configuration files.

Creating New Components

You can just create new Vue components as you normally would. However, Nx plugins also ship generators. They allow you to easily scaffold code, configuration or entire projects. Let's add the @nx/vue plugin to take advantage of the generators it provides.

To see what capabilities the @nx/vue plugin ships, run the following command and inspect the output:

Run the following command to generate a new "BaseButton" component. Note how we append --dry-run to first check the output.

As you can see it generates a new component in the src/components/ folder. If you want to actually run the generator, remove the --dry-run flag.

You're ready to go!

In the previous sections you learned about the basics of using Nx, running tasks and navigating an Nx workspace. You're ready to ship features now!

But there's more to learn. You have two possibilities here:

• Jump to the next steps section to find where to go from here or
• keep reading and learn some more about what makes Nx unique when working with Vue.

Modularize your Vue App with Local Libraries

When you develop your Vue application, usually all your logic sits in the src folder. Ideally separated by various folder names which represent your "domains". As your app grows, this becomes more and more monolithic though.

Nx allows you to separate this logic into "local libraries". The main benefits include

• better separation of concerns
• better reusability
• more explicit "APIs" between your "domain areas"
• better scalability in CI by enabling independent test/lint/build commands for each library
• better scalability in your teams by allowing different teams to work on separate libraries

Create a Local Library

Let's assume our domain areas include products, orders and some more generic design system components, called ui. We can generate a new library for these areas using the Vue library generator:

Note how we use the --directory flag to place the library into a subfolder. You can choose whatever folder structure you like to organize your libraries.

Nx tries to set up your workspace to work with the modular library architecture, but depending on your existing configuration, you may need to tweak some settings. In this repo, you'll need to do a few things in order to prepare for future steps.

Lint Settings

We want the lint task for the root vue-app project to only lint the files for that project, so we'll change the lint command in package.json:

Now we need to update the .eslintrc.cjs file to extend the .eslintrc.base.json file:

Build Settings

To make sure that the build can correctly pull in code from libraries, we need to move the typescript paths from the tsconfig.app.json file to the newly created tsconfig.base.json and extend that base file.

We also need to update vite.config.ts to account for typescript aliases. Run the following generator to automatically update your configuration file.

This will update the vite.config.ts file to include the nxViteTsPaths plugin in the plugins array.

Create More Libraries

Now that the repository is set up, let's generate the orders and ui libraries.

Running the above commands should lead to the following directory structure:

Each of these libraries

• has a project details view where you can see the available tasks (e.g. running tests for just orders: nx test orders)
• has its own project.json file where you can customize targets
• has a dedicated index.ts file which is the "public API" of the library
• is mapped in the tsconfig.base.json at the root of the workspace

Importing Libraries into the Vue Application

All libraries that we generate automatically have aliases created in the root-level tsconfig.base.json.

That way we can easily import them into other libraries and our Vue application. As an example, let's import the Products component from the products project into our main application. First, configure the router in the src/router/index.ts.

Then we can add links to the routes in App.vue.

Serving your app (nx serve) and then navigating to /products should give you the following result:

Visualizing your Project Structure

Nx automatically detects the dependencies between the various parts of your workspace and builds a project graph. This graph is used by Nx to perform various optimizations such as determining the correct order of execution when running tasks like nx build, identifying affected projects and more. Interestingly you can also visualize it.

Just run:

You should be able to see something similar to the following in your browser (hint: click the "Show all projects" button).

Notice how ui is not yet connected to anything because we didn't import it in any of our projects. Also the arrows to orders and products are dashed because we're using lazy imports.

Exercise for you: change the codebase so that ui is used by orders and products.

Imposing Constraints with Module Boundary Rules

Once you modularize your codebase you want to make sure that the modules are not coupled to each other in an uncontrolled way. Here are some examples of how we might want to guard our small demo workspace:

• we might want to allow orders to import from shared-ui but not the other way around
• we might want to allow orders to import from products but not the other way around
• we might want to allow all libraries to import the shared-ui components, but not the other way around

When building these kinds of constraints you usually have two dimensions:

• type of project: what is the type of your library. Example: "feature" library, "utility" library, "data-access" library, "ui" library (see library types)
• scope (domain) of the project: what domain area is covered by the project. Example: "orders", "products", "shared" ... this really depends on the type of product you're developing

Nx comes with a generic mechanism that allows you to assign "tags" to projects. "tags" are arbitrary strings you can assign to a project that can be used later when defining boundaries between projects. For example, go to the project.json of your orders library and assign the tags type:feature and scope:orders to it.

Then go to the project.json of your products library and assign the tags type:feature and scope:products to it.

Finally, go to the project.json of the shared-ui library and assign the tags type:ui and scope:shared to it.

Notice how we assign scope:shared to our UI library because it is intended to be used throughout the workspace.

Next, let's come up with a set of rules based on these tags:

• type:feature should be able to import from type:feature and type:ui
• type:ui should only be able to import from type:ui
• scope:orders should be able to import from scope:orders, scope:shared and scope:products
• scope:products should be able to import from scope:products and scope:shared

To enforce the rules, Nx ships with a custom ESLint rule.

Lint Settings

We want the lint task for the root react-app project to only lint the files for that project (in the src folder), so we'll change the lint command in package.json:

We need to update the .eslintrc.cjs file to extend the .eslintrc.base.json file and undo the ignorePattern from that config that ignores every file. The .eslintrc.base.json file serves as a common set of lint rules for every project in the repository.

Now we need to update the .eslintrc.base.json file and define the depConstraints in the @nx/enforce-module-boundaries rule:

When Nx set up the @nx/eslint plugin, it chose a task name that would not conflict with the pre-existing lint script. Let's overwrite that name so that all the linting tasks use the same lint name. Update the setting in the nx.json file:

Test Boundary Rules

To test the boundary rules, go to your modules/products/src/lib/products.tsx file and import the Orders from the orders project:

To test it, go to your modules/products/src/lib/products.vue file and import the Orders component from the orders project:

If you lint your workspace you'll get an error now:

Learn more about how to enforce module boundaries.

Migrating to a Monorepo

When you are ready to add another application to the repo, you'll probably want to move myvueapp to its own folder. To do this, you can run the convert-to-monorepo generator or manually move the configuration files.

Set Up CI for Your Vue App

This tutorial walked you through how Nx can improve the local development experience, but the biggest difference Nx makes is in CI. As repositories get bigger, making sure that the CI is fast, reliable and maintainable can get very challenging. Nx provides a solution.

• Nx reduces wasted time in CI with the affected command.
• Nx Replay's remote caching will reuse task artifacts from different CI executions making sure you will never run the same computation twice.
• Nx Agents efficiently distribute tasks across machines ensuring constant CI time regardless of the repository size. The right number of machines is allocated for each PR to ensure good performance without wasting compute.
• Nx Atomizer automatically splits large e2e tests to distribute them across machines. Nx can also automatically identify and rerun flaky e2e tests.

Connect to Nx Cloud

Nx Cloud is a companion app for your CI system that provides remote caching, task distribution, e2e tests deflaking, better DX and more.

Now that we're working on the CI pipeline, it is important for your changes to be pushed to a GitHub repository.

1. Commit your existing changes with git add . && git commit -am "updates"
2. Create a new GitHub repository
3. Follow GitHub's instructions to push your existing code to the repository

Now connect your repository to Nx Cloud with the following command:

A browser window will open to register your repository in your Nx Cloud account. The link is also printed to the terminal if the windows does not open, or you closed it before finishing the steps. The app will guide you to create a PR to enable Nx Cloud on your repository.

Once the PR is created, merge it into your main branch.

And make sure you pull the latest changes locally:

You should now have an nxCloudAccessToken property specified in the nx.json file.

Create a CI Workflow

Use the following command to generate a CI workflow file.

This generator creates a .github/workflows/ci.yml file that contains a CI pipeline that will run the lint, test, build and e2e tasks for projects that are affected by any given PR. Since we are using Nx Cloud, the pipeline will also distribute tasks across multiple machines to ensure fast and reliable CI runs.

The key lines in the CI pipeline are:

Open a Pull Request

Commit the changes and open a new PR on GitHub.

When you view the PR on GitHub, you will see a comment from Nx Cloud that reports on the status of the CI run.

The See all runs link goes to a page with the progress and results of tasks that were run in the CI pipeline.

For more information about how Nx can improve your CI pipeline, check out one of these detailed tutorials:

• Circle CI with Nx
• GitHub Actions with Nx

Next Steps

Connect with the rest of the Nx community with these resources:

• Join the Official Nx Discord Server to ask questions and find out the latest news about Nx.
• Follow Nx on Twitter to stay up to date with Nx news
• Read our Nx blog
• Subscribe to our Youtube channel for demos and Nx insights