Development - Managing the stores
This guide covers the core operations for managing stores in Alokai multistore projects through the Alokai CLI.
What You'll Learn
- How to create new stores using the CLI
- Understanding and modifying store configurations
- Moving stores within your project hierarchy
- Safely removing stores and handling cleanup
Why This Matters
When working with multiple brands and regions, keeping clean and maintainable repository is one of the most important characteristics that ensure you can keep releasing fast and with a high confidence. The Alokai CLI provides the tools you need to create, configure, and manage stores while keeping your codebase clean and structured.
Let's explore how to manage your stores effectively.
Adding a New Store
The store add
command guides you through creating a new store and sets up all necessary configurations:
yarn store add
Store Creation Flow
The CLI will ask several questions to configure your store:
- Store ID
- Unique identifier for your store
- Used in
alokai.config.json
,turbo.json
, and store directory - Example:
my-brand-us
- Parent Store
- Choose if this store inherits from existing store
- Or choose root to inherit from base apps
- Store Type
- Choose if store should be deployable or not. Template stores are not deployable.
- Console Project (for deployable stores only)
- The project name in Alokai Console
- If you're not sure, just skip it for now
- Can be updated later in
alokai.config.json
- Cloud Region (for deployable stores only)
- Deployment region for your store
- If you're not sure, just skip it for now
- Can be updated later in
alokai.config.json
What the Command Does
When you create a new store, the CLI:
- Updates Configuration Files
- Creates app-specific config files (
.prettierrc.mjs
,eslint.config.mjs
, etc.) - For deployable stores:
- Adds store entry to
alokai.config.json
- Updates
turbo.json
with build tasks and dependencies
- Adds store entry to
- Creates app-specific config files (
- Creates Store Directory Structure
- Sets up store directory with all required apps
alokai.config.json
Updates
For deployable stores, the CLI adds a new entry with default settings. All of these settings can be modified at any time:
{
"$schema": "./.alokai/alokaiConfigSchema.json",
"stores": {
"my-brand-us": {
"deployment": {
"framework": "nextjs", // Which frontend framework to deploy
"projectName": "my-project", // Your project in Alokai Console
"cloudRegion": "europe-west1" // Where to deploy
},
"localPorts": {
"middleware": 4001, // Port for local middleware
"nextjs": 3001, // Port for Next.js development
"nuxt": 3334 // Port for Nuxt development
},
"localDomain": "my-brand-us.local" // Domain for local development, when using `with-local-domains` flag
}
}
}
Important Things to Know:
- Template stores are not added to
alokai.config.json
as they're not meant to be deployed - All settings can be modified later by editing this file
- Remember to restart your development server after making changes
turbo.json
Updates
The CLI adds build tasks and dependencies to turbo.json
. These tasks ensure proper build order and caching:
{
"tasks": {
"storefront-middleware-my-brand-us#build": {
"dependsOn": ["^build"],
"inputs": ["**"],
"outputs": ["lib/**"]
},
"storefront-unified-nextjs-my-brand-us#build": {
"dependsOn": ["^build", "storefront-middleware-my-brand-us#build"],
"inputs": ["**"],
"outputs": [".next/**", "!.next/cache/**"]
},
"playwright-my-brand-us#test:integration:ui": {
"dependsOn": [],
"cache": false
}
}
}
Each task is named using the pattern {app-name}-{store-id}#{task-name}
. The tasks ensure:
- Middleware Build (
storefront-middleware-my-brand-us#build
)- Builds the middleware application first
- Generates TypeScript types needed by the frontend
- Caches the compiled output in
lib/
- Frontend Build (
storefront-unified-nextjs-my-brand-us#build
)- Waits for middleware to build (needs its types)
- Builds the Next.js application
- Caches the
.next
output (except cache directory)
- Integration Tests (
playwright-my-brand-us#test:integration:ui
)- Not cached as tests should run fresh each time
You can find more information about the tasks in the Turbo documentation.
Generated Store Structure
The CLI creates this directory structure for your store:
apps/stores/my-brand-us/
├── storefront-unified-nextjs/ # Next.js app overrides
├── storefront-unified-nuxt/ # Nuxt app overrides
└── storefront-middleware/ # Middleware overrides
└── playwright/ # Playwright tests
Moving Stores
The store move
command helps reorganize your store hierarchy:
yarn store move
Move Process
- Select the store to move
- Choose the new parent:
- Choose one of the existing stores as the new parent
- Or choose root to inherit from base apps
Don't move stores manually
Always use the store move
command instead of manually moving store directories. The CLI command handles several critical tasks: it updates all necessary configuration files, regenerates TypeScript configurations, and ensures proper inheritance chains.
Moving stores manually can break the build process, TypeScript configurations, and inheritance relationships in ways that are difficult to debug.
What Happens During a Move
When moving a store:
- Store configuration is updated in
alokai.config.json
tsconfig.json
is regenerated to inherit from the new parent- Store directory structure remains unchanged
Moving stores might not work out-of-the-box
Test your store thoroughly after moving it, as inheritance changes might affect its behavior. For example:
If your store uses a component from its parent:
// apps/stores/my-brand-us/storefront-unified-nextjs/app/page.tsx
import CustomHeader from '@/components/custom-header'
And this component was available in the old parent but doesn't exist in the new parent:
# Old parent had the component
apps/stores/fashion-brand/storefront-unified-nextjs/components/custom-header.tsx
# But new parent doesn't have it
apps/stores/sports-brand/storefront-unified-nextjs/components/custom-header.tsx # Missing!
Your store will fail to build after the move. To fix this, you can copy the component to your store directly, copy it to the new parent store, or refactor your store code to use a different component that exists in the new parent.
Best Practices for Moving Stores
- Plan the Move
- Figure out current store dependencies
- Plan testing strategy for affected stores
- Testing After Move
- Build and test the moved store
- Test stores that inherited from the moved store
- Verify all customizations still work
Removing Stores
Before removing a store, consider these alternatives:
- Could the store be moved to a different parent instead?
- Are there any dependent stores that need to be moved first?
To remove a store, you need to manually clean up several files:
- Remove Configuration Files
a. Delete the store's entry fromalokai.config.json
:{ "stores": { "my-brand-us": { // <- Remove this entire object "deployment": { "framework": "nextjs", "projectName": "my-project", "cloudRegion": "europe-west1" }, "localPorts": { "middleware": 4001, "nextjs": 3001, "nuxt": 3334 } } } }
b. Remove tasks fromturbo.json
:{ "tasks": { // Remove all tasks for the store "storefront-middleware-my-brand-us#build": { ... }, "storefront-unified-nextjs-my-brand-us#build": { ... }, "playwright-my-brand-us#test:integration:ui": { ... } } }
- Delete Store Files
# Remove the store directory
rm -rf apps/stores/my-brand-us
- Clean Build Cache
# Remove Turbo cache
rm -rf .turbo
Make Sure To:
- Move any dependent stores to new parents before removal
- Update any cross-store references in your codebase
- Remove store dependencies from
package.json
Next: Development - Using a local environment
Learn how to set up and use your local development environment effectively.