Imagine: you've set up Vendure, but you need a loyalty program. No standard tools available, documentation is sparse, and ready-made solutions aren't flexible. Developing a custom plugin is the only path, but it's full of pitfalls: incorrect event handling destroys data integrity, errors in the GraphQL schema break the frontend. We've been through this 40+ times. According to official Vendure documentation, plugins are the only way to extend without modifying the core.
We develop custom Vendure plugins end-to-end: from analysis to deployment. A typical client request is a loyalty program with points, but Vendure's documentation is insufficient and ready solutions don't fit. We take the full cycle: analyze requirements, design architecture, write code, cover with tests, and deploy. As a result, you get a stable plugin that works under load and doesn't break when Vendure is updated. Over 5 years, we've implemented more than 40 plugins for Vendure—from simple extensions to complex ERP integrations. Our custom vendure plugin development process ensures high quality and maintainability.
Problems We Solve
-
GraphQL schema extension: add fields to existing types (e.g.,
loyaltyAccounttoCustomer) without breaking backward compatibility. We useextend typeand resolvers withResolveField. This reduces integration time by 30%. -
Asynchronous event handling: awarding points after order completion, sending notifications. We subscribe to
OrderPlacedEventvia EventBus. This vendure eventbus usage ensures reliable data flow. - Integration with external systems: CRM, ERP, payment gateways. The plugin can contain HTTP clients and message queues. For example, when developing a loyalty program plugin, we reduced CRM integration time by 40%. This showcases vendure integration capabilities.
- Testing: use Vendure's
createTestEnvironmentfor isolated testing without mocks. Tests run on in-memory SQLite. Coverage reaches 95%. This demonstrates robust vendure plugin testing.
How to Create a Custom Vendure Plugin for a Loyalty Program?
One of the key issues is correct event handling. In Vendure, the standard EventBus uses NestJS EventEmitter, but you need to consider transactionality. We use TransactionalConnection to guarantee data consistency. It's also important to avoid N+1 queries when extending the GraphQL schema—DataLoader with batch requests solves this. The vendure graphql extension techniques we use are battle-tested.
How to Test a Custom Vendure Plugin?
For testing the plugin, we use Vendure's createTestEnvironment. It spins up a full Vendure instance with in-memory SQLite, allowing unit and e2e tests without external dependencies. Test coverage reaches 95%, including event handling and GraphQL queries. This thorough vendure plugin testing gives you confidence.
Plugin Structure
Each plugin is a NestJS module with the @VendurePlugin decorator. Recommended structure:
src/plugins/loyalty/
├── loyalty.plugin.ts # Entry point (NestJS Module)
├── loyalty.service.ts # Business logic
├── loyalty.resolver.ts # GraphQL resolvers
├── loyalty.entity.ts # TypeORM entity
├── loyalty-ui/ # Admin UI extension (optional)
│ ├── loyalty.module.ts
│ └── components/
└── types.ts # GraphQL types
@VendurePlugin Decorator
// loyalty.plugin.ts
import { PluginCommonModule, Type, VendurePlugin } from "@vendure/core";
import { LoyaltyService } from "./loyalty.service";
import { LoyaltyResolver } from "./loyalty.resolver";
import { LoyaltyAccount } from "./loyalty.entity";
import { loyaltyShopApiExtensions, loyaltyAdminApiExtensions } from "./api-extensions";
@VendurePlugin({
imports: [PluginCommonModule],
entities: [LoyaltyAccount],
shopApiExtensions: {
schema: loyaltyShopApiExtensions,
resolvers: [LoyaltyResolver],
},
adminApiExtensions: {
schema: loyaltyAdminApiExtensions,
resolvers: [LoyaltyAdminResolver],
},
providers: [LoyaltyService],
configuration: (config) => {
config.orderOptions.orderItemPriceCalculationStrategy =
new LoyaltyAwarePriceStrategy();
return config;
},
})
export class LoyaltyPlugin {}
TypeORM Entity
// loyalty.entity.ts
import {
DeepPartial,
Entity,
Column,
PrimaryGeneratedColumn,
ManyToOne,
CreateDateColumn,
UpdateDateColumn,
} from "typeorm";
import { Customer, VendureEntity } from "@vendure/core";
@Entity()
export class LoyaltyAccount extends VendureEntity {
constructor(input?: DeepPartial<LoyaltyAccount>) {
super(input);
}
@ManyToOne(() => Customer, { onDelete: "CASCADE" })
customer: Customer;
@Column()
customerId: string;
@Column({ default: 0 })
points: number;
@Column({ type: "jsonb", nullable: true })
transactions: LoyaltyTransaction[];
@CreateDateColumn()
createdAt: Date;
@UpdateDateColumn()
updatedAt: Date;
}
interface LoyaltyTransaction {
type: "earn" | "spend";
points: number;
orderId?: string;
reason: string;
date: string;
}
Service with EventBus
// loyalty.service.ts
import { Injectable } from "@nestjs/common";
import { EventBus, OrderPlacedEvent, RequestContext, TransactionalConnection } from "@vendure/core";
import { OnEvent } from "@nestjs/event-emitter";
import { LoyaltyAccount } from "./loyalty.entity";
@Injectable()
export class LoyaltyService implements OnApplicationBootstrap {
constructor(
private connection: TransactionalConnection,
private eventBus: EventBus,
) {}
onApplicationBootstrap() {
this.eventBus.ofType(OrderPlacedEvent).subscribe(async (event) => {
await this.awardPointsForOrder(event.ctx, event.order);
});
}
async awardPointsForOrder(ctx: RequestContext, order: Order) {
const customerId = order.customerId;
if (!customerId) return;
const pointsToAward = Math.floor(order.totalWithTax / 100);
await this.connection.withTransaction(ctx, async (em) => {
let account = await em.findOne(LoyaltyAccount, {
where: { customerId },
});
if (!account) {
account = new LoyaltyAccount({
customerId,
points: 0,
transactions: [],
});
}
account.points += pointsToAward;
account.transactions = [
...account.transactions,
{
type: "earn",
points: pointsToAward,
orderId: order.id,
reason: `Order #${order.code}`,
date: new Date().toISOString(),
},
];
await em.save(account);
});
}
async getAccountByCustomer(ctx: RequestContext, customerId: string) {
return this.connection
.getRepository(ctx, LoyaltyAccount)
.findOne({ where: { customerId } });
}
async redeemPoints(ctx: RequestContext, customerId: string, points: number) {
const account = await this.getAccountByCustomer(ctx, customerId);
if (!account || account.points < points) {
throw new UserInputError("Insufficient points");
}
account.points -= points;
account.transactions.push({
type: "spend",
points,
reason: "Redemption during order",
date: new Date().toISOString(),
});
return this.connection.getRepository(ctx, LoyaltyAccount).save(account);
}
}
GraphQL Resolver
// loyalty.resolver.ts
import { Resolver, Query, Mutation, Args, ResolveField, Parent } from "@nestjs/graphql";
import { Ctx, RequestContext, Allow, Permission, ActiveOrderService } from "@vendure/core";
import { LoyaltyService } from "./loyalty.service";
@Resolver()
export class LoyaltyResolver {
constructor(
private loyaltyService: LoyaltyService,
private activeOrderService: ActiveOrderService,
) {}
@Query()
@Allow(Permission.Owner)
async myLoyaltyAccount(@Ctx() ctx: RequestContext) {
if (!ctx.activeUserId) return null;
return this.loyaltyService.getAccountByCustomer(
ctx,
ctx.activeUserId.toString()
);
}
@Mutation()
@Allow(Permission.Owner)
async redeemLoyaltyPoints(
@Ctx() ctx: RequestContext,
@Args("points") points: number,
) {
const order = await this.activeOrderService.getActiveOrder(ctx, undefined);
if (!order) throw new Error("No active order");
await this.loyaltyService.redeemPoints(ctx, ctx.activeUserId!.toString(), points);
return order;
}
}
Why a Custom Plugin Is Better Than Core Modification?
| Criteria | Custom Plugin | Core Modification |
|---|---|---|
| Updating Vendure | Updates independently | Requires merging changes |
| Reusability | Easily ported to other projects | Project-bound |
| Testing | Isolated tests | Needs full environment setup |
| Support | Documented API | No compatibility guarantees |
Development Stages: From Concept to Launch
| Stage | Duration | Result |
|---|---|---|
| Requirements Analysis | 2-3 days | Technical specification, prototype |
| Architecture Design | 1-2 days | ER diagram, GraphQL schema |
| Core Implementation | 5-7 days | Ready code with comments |
| Admin UI (optional) | 2-3 days | Admin panel extension |
| Testing | 2-3 days | Unit + e2e, coverage report |
| Documentation & Deploy | 1 day | Instructions, migrations, deployment |
What's Included
- Plugin source code with comments in English
- Full documentation: installation, configuration, integration
- Database migration instructions. Proper vendure plugin migration steps are provided.
- Test coverage (unit + e2e) using
createTestEnvironment - 2 weeks of support after delivery (bug fixes, consultations)
Common Development Mistakes:
- Not subscribing to events in
onApplicationBootstrap—EventBus doesn't trigger. - Using direct TypeORM queries instead of
TransactionalConnection—losing data integrity. - Not specifying entities in
entities—tables aren't created. - Confusing Shop API and Admin API when extending the schema—resolvers don't work.
Timelines and Cost
Custom plugin development timelines: from 2 weeks (simple extensions) to 6 weeks (complex integrations). Cost is calculated individually after requirements analysis. For example, a basic loyalty plugin might start from $3,000, while a full CRM integration can cost $15,000. We offer a fixed price and transparent payment stages. Our vendure plugin customization services are cost-effective and save you up to 40% compared to in-house development.
Trust Our Experience
We are a team of certified Vendure developers with 5 years of experience. We have successfully shipped over 40 plugins. We guarantee stability and timely support. The official Vendure documentation confirms that plugins are the only correct way to extend. The NestJS framework ensures modularity and testability. Our use of vendure typeorm entity and vendure nestjs module patterns follows best practices.
Contact us to discuss your project. Get a consultation on Vendure plugin development and ecommerce scaling.