Power Apps Code App: Pick Any Vite Framework

A Power Apps code app is just any other app built with the Vite build tool, and that single fact unlocks your whole frontend toolbox. The official Microsoft template ships React with TypeScript, so many makers assume React is mandatory. It is not. Because the platform glue lives in the Vite layer, you can build a Power Apps code app with the framework your team already knows. This guide proves that claim with builds we actually tested, and it gives you one recipe that works across stacks.

A Power Apps code app running locally across several Vite frameworks

Note (updated October 2026): the CLI has moved twice. The old pac code commands were replaced by an npm CLI that shipped inside the SDK package, and that has in turn been replaced by the standalone @microsoft/power-apps-cli package, which installs the pa command (pa app init, pa app run, pa app push). Only the pa CLI gets new features, so that is what this walkthrough uses. Code apps are generally available, and the recipe below was re-verified with CLI 1.3.0.

Table of Contents

What actually makes a Power Apps Code App

To understand why framework choice is free, look at what the platform requires. Specifically, three framework-agnostic pieces turn any Vite app into a Power Apps code app.

First, the @microsoft/power-apps package provides the SDK, and the separate @microsoft/power-apps-cli package provides the pa CLI, which runs pa app init, pa app run, and pa app push. Second, the @microsoft/power-apps-vite package provides a Vite plugin called powerApps(). That plugin sets the asset base path to relative, configures CORS for the player domains, serves your power.config.json, and prints the Local Play URL. Third, the power.config.json file points the app at your environment and needs little more than an environment id.

Notably, none of these pieces is React-specific. Moreover, the current template carries no provider component and no init call in application code. Therefore the work that once felt React-shaped now lives entirely in Vite and the SDK. That is precisely why a Power Apps code app runs on any Vite stack.

The tested results

We did not assume compatibility; instead, we scaffolded each stack, added the plugin, and ran a production build. A build counts as a pass when it exits cleanly and emits relative ./assets/... paths in dist/index.html, because that relative path proves the powerApps() plugin took effect.

Framework	Slot-in effort	Bundle
React (official)	built in	~223 KB
Vue	one plugin line	~66 KB
Svelte	one plugin line	~31 KB
Solid	one plugin line	~15 KB
Preact	one plugin line	~18 KB
Angular	Vite-native setup	~95 KB

Bundle sizes are the main JavaScript file in dist/assets after npm run build, measured again in October 2026 with Vite 8 (the React template pins Vite 7).

In short, five of six stacks are literal drop-ins. Angular is the instructive exception, which we cover below.

One recipe for any create-vite stack

Because the glue is shared, the path is the same for React, Vue, Svelte, Solid, and Preact. First, scaffold any Vite template (below is an example for Vue with TypeScript):

npm create vite@latest my-app -- --template vue-ts
cd my-app
npm install

If create-vite asks Install with npm and start now?, answer No and run the cd and npm install lines yourself. Saying Yes also starts the dev server, which you do not need yet. The commands are shown one per line on purpose: Windows PowerShell 5.1 rejects && between commands, while PowerShell 7, cmd and bash accept either form.

Terminal: npm create vite scaffolds the Vue TypeScript template and npm install adds the dependencies

Next, add the SDK and the Vite plugin:

npm install @microsoft/power-apps
npm install -D @microsoft/power-apps-vite

Terminal: npm install adds the @microsoft/power-apps SDK and the @microsoft/power-apps-vite plugin

Then add powerApps() to the plugins array in vite.config.ts:

import { powerApps } from '@microsoft/power-apps-vite/plugin'
// plugins: [<framework-plugin>(), powerApps()]

Terminal: vite.config.ts with the Vue plugin and powerApps() in the plugins array

After that, install the Power Apps CLI once (it provides the pa command), then bind the app to your environment. The init command opens a browser sign-in if you are not signed in yet, adds the CLI to the project as a dev dependency, and writes power.config.json. Its output ends with a hint to run npm install again; that installs the project-local copy of the CLI and is optional, because the global pa command already works:

npm install --global @microsoft/power-apps-cli
pa app init -n "My App" -e <environment-id>

Terminal: pa app init creates power.config.json for My Vue App in the chosen environment

Finally, develop and publish:

pa app run
npm run build
pa app push

For hardcore javascript developers, the scaffolding templates can be changed from e.g. vue-ts to vue). Keep in mind that generated services and models are .ts files anyways. Which means that when you run pa app add data-source --connector dataverse --table account, the output in src/generated/ is TypeScript: typed interfaces for each table, typed enums for choice columns, typed service methods. Vite transpiles .ts via esbuild whether your own code is JS or TS, so this works in a JS project — but you’d be reading TS to use them, and you’d lose all the type-safety on Dataverse column names and types…

When pa app run starts the dev server, the plugin prints a Local Play URL; open it in the same browser profile as your Power Platform tenant, and accept the browser’s Local Network Access prompt the first time: Chrome and Edge block calls from the player to localhost until you do. After the push, the CLI returns a live app URL.

Terminal: pa app run starts the dev server and the Power Apps Vite plugin prints the Local Play URL

Terminal: npm run build emits dist/index.html with relative ./assets paths, proof that the powerApps() plugin is active

Terminal: pa app push publishes the build and returns the live Power Apps URL

This is what you should see when you open the live app URL: the app running inside Power Apps after pa app push, with the name you gave pa app init in the header.

The finished Vue code app running inside Power Apps, with the app name from pa app init in the header

I have created a quick-guide/cheatsheet on how to configure each and every one of them, so that you can come back and refer to them again in the future:

Choosing your Power Apps code app stack

Each framework brings a different trade-off, so pick the one your organization/team will maintain happily. I made this post, because different companies that I’ve been working with has different stack defined as standards across the developer teams (aka. standardised Design System).

For the smoothest start, a React code app needs zero setup, since the official template is already wired.
For a popular and approachable alternative, a Vue code app drops in with one plugin line.
For the lightest footprint, a Svelte code app compiles components away.
For the smallest bundle and fine-grained reactivity, a SolidJS code app is hard to beat.
For the easiest React migration, a Preact code app keeps the React API at a fraction of the size.
For Angular teams, an Angular code app works too, although it needs a Vite-native setup (using AnalogJS) which requires some additional technical knowledge.

Angular is the exception

Angular deserves a special mention, because it has a smaller boundary. Unlike the others, Angular is not a create-vite template, and its CLI hides the Vite config you would normally edit. Therefore you cannot simply add the powerApps() plugin to a plugins array.

To make an Angular code app, you run Angular on a Vite config you control through the AnalogJS vite-plugin-angular. Once you do, the same three pieces apply and the build passes. However, watch the tsconfig: A misconfigured tsconfig.app.json can produce an empty bundle while still reporting success.

Connecting to data is also framework-neutral

Based on what you’ve read so far, you should get the hint that data access does not change based on the framework you choose to work with. When you add a connector for Dataverse, SharePoint, or Office 365, the CLI generates plain TypeScript services under src/generated/. Because those services carry no framework dependency, you call XxxService.getAll() from a React hook, a Vue composable, a Svelte store, a Solid resource, or an Angular service. As a rule, keep the connector surface small; aim for ten connectors or fewer per app to avoid load-time and save issues.

How we tested every stack

Because claims are cheap, we validated each framework the same way. First, we scaffolded the project and added the powerApps() plugin. Next, we created a placeholder power.config.json so the tooling had an environment id to read. Then we ran the production build and inspected the output. Finally, we confirmed two things: the build exited cleanly, and dist/index.html referenced its assets with relative paths. Every stack in the table cleared that bar, which is why we can recommend any of them with confidence.

This was deliberately a local build check rather than a full deploy. Update, October 2026: the recipe was re-run end to end with the pa CLI 1.3.0 against a live environment, including init, run and push, and the terminal screenshots in the framework guides come from that run.

The takeaway

A Power Apps code app frees you from a single-framework mandate. Because the glue is a Vite plugin plus a small config, your existing skills transfer directly. So start from the stack your team knows, follow the shared recipe, and ship.

For the authoritative platform reference, see the Power Apps code apps documentation on Microsoft Learn.