DEV Community: Othmane Nemli

Laravel Context: The Hidden Information That Follows Your Code

Othmane Nemli — Sun, 27 Sep 2026 17:33:15 +0000

When working with Laravel, we usually pass data explicitly:

$user = auth()->user();
UserExampleService::process($user);

Or we add information directly to a log:

Log::info('Processing order', [
    'order_id' => $order->id,
]);

But what if you have some information that should be available throughout the current execution?

For example:

a trace ID
the current URL
a tenant ID
an operation name
information needed by logging
information that should follow a queued job

This is where Laravel's Context feature becomes interesting.

What is Laravel Context?

Laravel Context provides a place to store information that belongs to the current execution of your application.

You can add data:

use Illuminate\Support\Facades\Context;

Context::add('trace_id', 'abc-123');

And retrieve it somewhere else:

$traceId = Context::get('trace_id');

The interesting part is that you don't have to keep passing $traceId through every method.

The information lives in the current context and can be consumed by other parts of the application.

Laravel specifically describes Context as a way to capture, retrieve, and share information across requests, jobs, and commands. It also integrates that information with application logs.

The simplest example

Imagine middleware generating a trace ID for every request:

use Illuminate\Support\Facades\Context;
use Illuminate\Support\Str;

Context::add('trace_id', Str::uuid()->toString());

Now somewhere deep inside your application:

$traceId = Context::get('trace_id');

No controller parameter.
No service parameter.
No global variable.

The data is simply part of the current context.

The really useful part: logging

Context becomes particularly useful when combined with logging.

For example:

Context::add([
    'trace_id' => Str::uuid()->toString(),
    'url' => $request->url(),
]);

Then later:

Log::info('User authenticated', [
    'user_id' => $user->id,
]);

The log entry can contain both the information explicitly passed to the log and the information stored in Context:

User authenticated
{
    "user_id": 27,
    "trace_id": "e04e1a11-...",
    "url": "https://dev.to/login"
}

This is useful because you can establish information once and have it accompany subsequent log entries instead of manually adding it everywhere.

But here's where Context gets interesting

Imagine this happens:

HTTP Request
     │
     |--- Controller
     │      │
     │      |--- Service
     │             │
     |             |--- context
     │             |--- Dispatch Job
     │
     v
 Job Payload (Context captured, dehydrated, and stored within payload)
     │
     v
 Queu
     │
     v
 Worker
     │
     v hydarte -> restore Context
     │
     v
Job Execution

Normally, the HTTP request and the queued job are two different executions.

So how would the job know about the context created during the original request?

Laravel handles this for you, when a job is dispatched, Laravel captures the current context and stores it with the job's payload.

When the worker starts processing the job, that context is restored into the current execution, Laravel calls these two stages dehydrating and hydrating.

So this:

Context::add('trace_id', 'abc-123');

ProcessPodcast::dispatch($podcast);

can result in the job seeing:

Context::get('trace_id');
// "abc-123"

And therefore:

Log::info('Processing podcast');

can still contain the original trace information. That's a surprisingly powerful feature for debugging distributed workflows.

So Context is not a global variable shared between processes.

Gere's the interesting part

Laravel's queue worker is a long-running process, it processes one job, then another:

Worker
 │
 |--- Job A
 │
 |--- Job B
 │
 |--- Job C
 │
 |--- Job D

If Context were simply stored globally and never cleaned up, you could have:

Job A
trace_id = abc-123

Job B
trace_id = abc-123  (this is bad)

Laravel therefore has lifecycle management around the worker (registerWorker()). The queue service provider's worker reset logic flushes shared logging context and clears scoped instances between jobs, among other cleanup operations.

Context can also be hidden

Not everything you put into Context should appear in your logs.Laravel provides hidden context for exactly this purpose:

Context::addHidden('internal_hidden_id', 123);

Context::getHidden('internal_hidden_id');
// 123

But:

Context::get('internal_hidden_id');
// null

Hidden context isn't appended to log entries and uses a separate API.

This gives you two different kinds of context:

Context
|-- Normal data
│   |--- Can be included in logs
│
|-- Hidden data
    |--- Available to your application, but not included in logs.

That distinction becomes especially useful when context contains internal information that shouldn't become part of your application logs.

Laravel itself uses hidden Context internally.

In CallQueuedHandler, Laravel can store information such as:

laravel_unique_job_cache_store
laravel_unique_job_key
laravel_unique_job_lock_owner

Why? There is a situation where Laravel may not be able to unserialize a queued job because a model is missing.

In that case, Laravel still needs enough information to release the unique-job lock.

The handler retrieves those values from the hidden Context and uses them to restore/release the lock

Context can have a lifecycle

Laravel also lets you hook into the moment context crosses the queue boundary.

Typically, you should register dehydrating/hydrated callbacks within the boot method of your application's AppServiceProvider class:

For example:

Context::dehydrating(function (Repository $context) {
    // Prepare context before it is attached to a job
    $context->addHidden('locale', Config::get('app.locale'));
});

And:

Context::hydrated(function (Repository $context) {
    // Restore or use context when the job starts
     if ($context->hasHidden('locale')) {
        Config::set('app.locale', $context->getHidden('locale'));
    }
});

This means Context isn't simply a static array sitting somewhere.

Laravel gives you hooks around the transition from one execution environment to another.

One important detail from the Laravel documentation: inside these callbacks, you should modify the $context repository provided to the callback rather than calling the Context facade itself.

Context is more than key/value storage

There are some useful features beyond add() and get().

For example, you can store a stack:

Context::push('breadcrumbs', 'checkout');
Context::push('breadcrumbs', 'payment');

Context::get('breadcrumbs');

You can also retrieve a value and remove it at the same time:

$value = Context::pull('key');

Or remember a value only when it doesn't already exist:

$permissions = Context::remember(
    'user-permissions',
    fn () => $user->permissions,
);

Laravel also provides has, missing, forget, only, except, and corresponding hidden-context methods.

You don't need all of these every day. The important thing is understanding what Context is designed for.

When should you use it?

Context is particularly interesting when information belongs to an execution flow, rather than to a particular function.

For example:

Request
   │
   |--- Middleware
   │
   |--- Controller
   │
   |--- Service
   │
   |--- Event
   │
   |--- Queue Job
   │
   |-- Logs

A value such as:

trace_id = abc-123

can describe the entire operation rather than one particular method; That's where Context shines, so instead of doing this everywhere:

processOrder($order, $traceId);

you can keep the trace information in Context:

Context::get('trace_id');

and let the framework carry it through the execution flow.

One important rule

Context is not a replacement for normal application data, don't put everything into it, a useful mental model is:

Arguments describe what a function needs. Context describes what is happening around the current execution.

For example:

processOrder($order);

makes sense because $order is an input to the operation.

But:

Context::add('trace_id', $traceId);

makes sense because the trace ID describes the execution surrounding that operation.

At the end, is it another Laravel key/value?

The API itself is simple:

Context::add(...)
Context::get(...)

The interesting part is what Laravel does with that information.

It can:

attach it to logs,
carry it from an HTTP request into a queued job,
restore it when the job starts,
keep hidden data separate from log data,
and give your application hooks around that transfer.

So the next time you see:

Context::add('trace_id', $traceId);

don't think of it as just another Laravel key/value store, think of it as metadata attached to an execution flow, and that's what makes Laravel Context much more interesting than it first appears.

Sources:
Context Doc

Vite+ — Chapter 5: Should You Use Vite+?

Othmane Nemli — Sat, 26 Sep 2026 13:56:21 +0000

We've reached the final chapter.

Now comes the question every developer eventually asks when evaluating a new tool:

Should I actually use it?

The answer depends on your project.

Vite+ isn't something you need to add to every JavaScript application just because it exists.

Instead, it's worth understanding what problems it solves, what it changes, and whether those problems actually exist in your project.

1. First: What Is Vite+ Really?

Let's summarize the entire series in one sentence:

Vite+ is an integrated JavaScript toolchain built around Vite and other modern tools from the VoidZero ecosystem.

It brings together tools such as:

Vite
Vitest
Rolldown
tsdown
Oxlint
Oxfmt
Vite Task

and exposes them through the vp command.

For example:

vp dev
vp test
vp check
vp build
vp run

The important part isn't simply having fewer commands.

The bigger idea is having a more integrated development environment.

2. The Problem Vite+ Is Trying to Solve

Modern JavaScript projects often look something like this:

                    package manager
                          │
          ┌───────────────┼───────────────┐
          │               │               │
        Vite            Vitest        TypeScript
          │               │               │
       Build             Test          Type check
          │               │               │
       ESLint           Prettier       Task runner
          │               │               │
          └───────────────┴───────────────┘
                          │
                         CI

Each tool can be good at its job.

The problem is the connections between them.

You eventually have to answer questions like:

Which tool should I use?
Which configuration file controls it?
Which version should I install?
How do these tools interact?
How should CI run them?
How should they work in a monorepo?
Which tasks depend on each other?
Which results can be cached?

Vite+ tries to reduce some of that complexity.

3. When Vite+ Makes Sense

There are several situations where Vite+ can be particularly interesting.

Growing projects

Maybe your application started small.

You had:

src/
package.json
vite.config.ts

Then six months later:

src/
tests/
packages/
scripts/
apps/
.github/

The project has grown.

Now you're maintaining:

development tooling
tests
formatting
linting
builds
CI
multiple packages

This is where a unified toolchain can become more valuable.

4. Teams That Want Consistency

Imagine a team of 20 developers.

Developer A runs:

npm run lint
npm run test
npm run build

Developer B runs:

pnpm lint
pnpm test
pnpm build

Developer C has a custom script:

./scripts/check-everything.sh

And CI has:

some completely different collection of commands

It works, but it creates cognitive overhead.

With Vite+, the team can establish a simpler vocabulary:

vp check
vp test
vp build

New developers have fewer project-specific commands to memorize.

5. Monorepos

This is probably one of the most interesting scenarios.

Suppose your repository contains:

apps/
├── web/
├── admin/
└── docs/

packages/
├── ui/
├── utils/
├── api/
└── config/

Now you have:

package dependencies
task dependencies
build ordering
caching
parallel execution
CI optimization

This is where vp run and Vite Task become much more relevant.

Instead of treating every package as an isolated project, the task system can reason about the repository as a whole.

For example:

vp run build

can operate across the task graph rather than simply executing one script in one directory.

6. When Vite+ May Not Be Necessary

Now let's look at the other side.

Imagine you're building:

my-portfolio/
├── src/
├── public/
├── package.json
└── vite.config.ts

You have:

one application
one developer
a handful of dependencies
a simple deployment pipeline

Your current workflow might already be:

npm run dev
npm run test
npm run build

And everything works.

In that situation, introducing another layer may not provide enough value to justify changing your workflow.

That's an important lesson when evaluating developer tools:

A tool doesn't need to solve a problem you don't have.

7. Don't Adopt Tools Just Because They're New

This is especially important with developer tooling.

A new tool can be:

technically interesting
faster
beautifully designed
backed by a respected team

and still not be necessary for your project.

Before adopting Vite+, ask:

What problem am I trying to solve?

Not:

What new tool should I install?

The first question leads to better engineering decisions.

8. What About Existing Vite Projects?

This is probably the most common question.

Suppose you already have a Vite application.

You might have:

my-app/
├── src/
├── public/
├── package.json
├── vite.config.ts
├── vitest.config.ts
├── eslint.config.js
└── prettier.config.js

Do you need to throw everything away?

No.

Vite+ is designed to work with existing projects and provides migration tooling.

The migration workflow can be started with:

vp migrate

The migration process can help bring an existing project toward the Vite+ setup, but you should still review the changes carefully. The project is in beta, and complex repositories may require manual adjustments. (voidzero.dev)

Migration should therefore be treated as an engineering change, not just a dependency update.

9. Migration Is More Than Changing Commands

Imagine your current project has:

ESLint
Prettier
Vitest
Vite
TypeScript
custom scripts
GitHub Actions

Moving to Vite+ potentially changes several parts of your workflow.

You should check:

Development

Does:

vp dev

behave as expected?

Tests

Do your existing tests work with:

vp test

Formatting

Does your codebase produce the formatting you expect?

Linting

Do existing lint rules still behave as expected?

CI

Does your pipeline still produce the same artifacts?

Builds

Does:

vp build

produce the expected output?

A successful migration isn't simply:

Command completed successfully

It's:

The project still behaves correctly.

10. Vite+ Is Still Evolving

This point is important.

Vite+ is currently a beta project.

That means you should expect the project to evolve before reaching its stable 1.0 release. The official announcement describes Vite+ as being developed toward a 1.0 release and invites developers to try the beta and provide feedback. (voidzero.dev)

For developers, this has two sides.

You get to experiment with a modern toolchain early.

But you also need to accept that:

APIs can evolve
configuration can change
documentation can change
workflows can be refined
bugs can still appear

That's normal for beta software.

11. Beta Doesn't Mean "Don't Use It"

Beta software isn't automatically unusable.

It simply means you should understand the risk.

There is a big difference between:

Trying Vite+ on a side project

and:

Replacing the entire toolchain
of a mission-critical production system

The amount of validation you need should match the importance of the project.

For example:

Experiment

Personal project
     ↓
Try Vite+
     ↓
See how it feels

Team project

Evaluate
   ↓
Prototype
   ↓
Test CI
   ↓
Test production build
   ↓
Document workflow
   ↓
Adopt

The second process takes longer.

That's appropriate because the cost of failure is higher.

12. What About Performance?

Performance is one of the reasons modern JavaScript tooling is evolving.

VoidZero is building tools such as:

Rolldown
Oxc
Vite
Vitest

with an emphasis on performance and integration.

Some of the lower-level tools are implemented in Rust, including the Oxc toolchain and Rolldown.

But there's an important distinction:

A faster individual tool doesn't automatically make your entire development workflow faster.

Your real development experience depends on many things:

Tool speed
+
Project size
+
Configuration
+
Dependency graph
+
Task scheduling
+
Caching
+
CI environment

So don't evaluate Vite+ only by looking at benchmark numbers.

Try it on a project that resembles your real workload.

13. Developer Experience Matters Too

Performance is only one part of developer experience.

Consider how often developers type:

npm run dev
npm run lint
npm run format
npm run test
npm run build

Now compare that with:

vp dev
vp check
vp test
vp build

The difference isn't enormous.

But over hundreds of days, small sources of friction add up.

More importantly, a consistent interface can make a project easier to explain.

For a new developer:

How do I check the project?

Answer:

vp check

How do I run tests?

Answer:

vp test

How do I build it?

Answer:

vp build

Simple conventions are valuable.

14. But Don't Ignore Your Existing Ecosystem

Every project has dependencies outside its main build tool.

You might use:

Storybook
Playwright
Cypress
Tailwind
Next.js
Nuxt
custom deployment tools
internal scripts

Not every project will benefit equally from moving toward Vite+.

You should check compatibility with the tools that matter to your specific application.

For example, don't start a migration by asking:

"Can Vite+ replace everything?"

Instead ask:

"Can Vite+ improve the parts of our workflow that currently cause problems?"

That's a much safer approach.

15. A Practical Evaluation Strategy

If you're considering Vite+, don't immediately migrate your biggest production repository.

Start small.

Step 1 — Pick a representative project

Choose something that has enough complexity to expose real problems.

Not:

hello-world/

and not necessarily:

our-most-important-production-system/

Something in between is ideal.

Step 2 — Establish a baseline

Before migrating, measure:

Install time
Build time
Test time
CI time
Developer workflow

For example:

Current:

Install → 35s
Tests   → 50s
Build   → 80s
CI      → 4m 20s

Now you have something to compare against.

Step 3 — Migrate

Try:

vp migrate

Review the changes.

Then run:

vp check
vp test
vp build

Step 4 — Test CI

Don't stop at:

"It works on my laptop."

Run the actual CI workflow.

Check:

dependency installation
tests
linting
formatting
build output
caching
deployment artifacts

Step 5 — Compare

Now you have real information.

For example:

                    Before       After

Install             35s          30s
Tests               50s          40s
Build               80s          55s
CI                  4m20s        3m10s

These numbers are only an example.

Your results may be completely different.

The point is to measure your project, not someone else's benchmark.

16. The Most Important Lesson

After all five chapters, there's one idea I think is worth remembering.

Vite+ isn't primarily interesting because:

vp dev

is shorter than:

npm run dev

That's not the real story.

The interesting part is the integration.

Think about the entire workflow:

                 Vite+
                   │
        ┌──────────┼──────────┐
        │          │          │
      Develop    Test       Check
        │          │          │
       Vite      Vitest    Oxlint/Oxfmt
        │
      Build
        │
    Rolldown
        │
        ▼
   Task system
        │
        ▼
   Monorepo / CI

The goal is to make these pieces work together as one development environment.

That's the bigger idea.

17. Vite+ Doesn't Make Individual Tools Disappear

This is another important distinction.

When you run:

vp test

Vitest doesn't suddenly stop existing.

When you run:

vp build

Vite and Rolldown don't stop existing.

When you run:

vp check

the underlying checking tools still matter.

Vite+ provides the integration layer.

Conceptually:

             Your project
                  │
                  ▼
                Vite+
                  │
       ┌──────────┼──────────┐
       ▼          ▼          ▼
     Vite       Vitest     Oxc tools
       │          │          │
       └──────────┼──────────┘
                  ▼
             Task system

This is why understanding the individual tools from Chapter 2 was important.

Vite+ doesn't remove the concepts.

It connects them.

19. To wrap things up

JavaScript tooling has become incredibly powerful.

But that power also created complexity.

We have excellent tools for:

development
bundling
testing
linting
formatting
packaging
task execution

The challenge is making all of them work together without creating unnecessary maintenance work.

That's the space Vite+ is trying to address.

Whether it becomes the standard way teams build JavaScript applications remains something the ecosystem will determine over time.

For developers, the interesting part is the direction:

More integrated tooling
        ↓
Less configuration
        ↓
Better coordination
        ↓
Faster feedback
        ↓
Simpler workflows

And that's worth paying attention to.

You don't need to migrate every project tomorrow.

You don't need to replace tools that already work.

But if you're building a new project, maintaining a growing monorepo, or regularly fighting with your JavaScript toolchain, Vite+ is certainly a project worth understanding and evaluating.

And now, when you see:

vp dev
vp check
vp test
vp build
vp run

you know what's happening behind those commands.

And that's the real story behind Vite+.

I hope you enjoyed following this series and that it helped answer your questions and gave you a clearer understanding of the topic. Thanks for reading, and I hope you found it useful!

Vite+ — Chapter 4: Vite+ at Scale — Monorepos, Tasks, Caching, and CI

Othmane Nemli — Sat, 26 Sep 2026 12:08:38 +0000

In the previous chapter, we used Vite+ for a normal application:

vp dev
vp check
vp test
vp build

That workflow is already useful.

But there's another situation where Vite+ becomes much more interesting:

What happens when your project becomes a lot bigger?

Imagine that one application becomes five, then you add shared UI components, then shared utilities, then a design system, then internal libraries.

Eventually, your repository might look like this:

company-project/
├── apps/
│   ├── web/
│   ├── admin/
│   └── docs/
│
├── packages/
│   ├── ui/
│   ├── utils/
│   ├── config/
│   └── api/
│
└── package.json

This is a monorepo.

And this is where running every task all the time can become expensive.

Vite+ includes Vite Task specifically to handle dependency-aware task execution and caching in monorepos.

1. What Is a Monorepo?

Before talking about Vite+, let's understand the problem.

A monorepo is simply a repository containing multiple projects or packages.

For example:

my-company/
│
├── apps/
│   ├── web/
│   └── mobile/
│
└── packages/
    ├── ui/
    ├── utils/
    └── types/

Here we might have:

web → the main website
mobile → a mobile application
ui → shared UI components
utils → shared utilities
types → shared TypeScript types

The advantage is that everything lives together.

A developer can change a shared package and immediately test the applications that use it.

But this also creates a new problem:

Which tasks actually need to run?

2. The Dependency Problem

Let's say we have:

web
 │
 └── ui
      │
      └── utils

This means:

web depends on ui
ui depends on utils

Now imagine you change something inside:

packages/utils/

Should we rebuild everything? Maybe.

But what if you only changed:

apps/docs/

Do we really need to rebuild web? Probably not.

A large monorepo can contain hundreds of tasks.

Running all of them after every small change wastes time.

This is where a task system becomes important.

3. What Is a Task?

A task is simply something your project needs to do.

For example:

build
test
lint
typecheck

A package might have:

{
  "scripts": {
    "build": "vite build",
    "test": "vitest",
    "lint": "oxlint"
  }
}

These are tasks, in a small application, running them manually isn't difficult.

In a monorepo, however, you might have:

20 packages
×
4 tasks
=
80 possible tasks

Now the task runner has a much bigger job.

4. Enter `vp run`

Vite+ provides:

vp run

This command can run package scripts and monorepo tasks while understanding dependencies between them. It also supports task caching.

For example:

vp run build

You can think of this as saying:

"Run the build tasks that are relevant to this project."

Instead of manually navigating through every package.

5. Task Dependencies

Let's use a simple example.

Imagine:

packages/utils
       ↓
packages/ui
       ↓
apps/web

The relationships are:

utils
  ↓
ui
  ↓
web

If web needs ui, and ui needs utils, then the build order matters.

You can't necessarily build:

web

before:

ui

and you can't build:

ui

before:

utils

The dependency graph is therefore:

utils
  │
  ▼
 ui
  │
  ▼
web

A task runner can use this graph to determine what needs to happen first.

6. Why Dependency-Aware Execution Matters

Imagine your repository contains:

apps/
├── web
├── admin
└── docs

packages/
├── ui
├── utils
├── api
└── config

Suppose:

web → ui → utils
admin → ui → utils
docs → ui

If utils changes, both web and admin may be affected.

But docs might not depend directly on utils.

A dependency-aware task runner can use those relationships instead of blindly running everything.

Conceptually:

utils changed
     │
     ├── ui
     │    ├── web
     │    └── admin
     │
     └── unrelated packages
          ↓
        skip

That's the important idea.

7. Caching

Now we reach one of the most useful features.

Imagine you run:

vp run build # takes 45 seconds

Then you run the exact same command again.

If nothing relevant changed, rebuilding everything from scratch is unnecessary.

This is where caching comes in.

Conceptually:

First run

Source code
    ↓
Build
    ↓
45 seconds
    ↓
Save result

Then:

Second run

Same inputs
    ↓
Cache lookup
    ↓
Reuse previous result

Instead of "45 seconds", you can potentially get a result much faster.

Vite+ describes vp run as providing caching and dependency-aware scheduling for monorepo tasks.

8. What Does the Cache Actually Mean?

A common misunderstanding is:

"The cache means Vite+ never runs the command again."

That's not quite right.

The important question is whether the task's relevant inputs have changed.

Think about:

Input
 ↓
Task
 ↓
Output

For example:

src/
package.json
tsconfig.json
environment
     ↓
   build
     ↓
   dist/

If the inputs are unchanged, the previous result may be reusable.

If an important input changes:

src/Button.tsx

then the task may need to run again.

Conceptually:

Same inputs
    ↓
Cache hit
    ↓
Reuse result

versus:

Changed inputs
    ↓
Cache miss
    ↓
Run task again

This is the basic idea behind task caching.

9. Cache Hits and Cache Misses

You'll often hear two terms:

Cache hit

The previous result can be reused.

web#build — cache hit

Cache miss

The task needs to run again.

web#build — cache miss

For example:

First run:

utils#build   → cache miss
ui#build      → cache miss
web#build     → cache miss

Everything has to run.

Then you run it again without changing anything:

Second run:

utils#build   → cache hit
ui#build      → cache hit
web#build     → cache hit

The exact behavior depends on the task inputs and configuration, but this is the mental model developers should have.

10. Why This Matters in CI

Now let's move from your laptop to CI.

A typical CI pipeline might look like:

Developer pushes code
        ↓
     GitHub
        ↓
     CI starts
        ↓
    Install deps
        ↓
      Check
        ↓
      Test
        ↓
      Build

Without caching, every CI run may repeat expensive work.

Imagine:

Install     → 30 sec
Lint        → 20 sec
Tests       → 60 sec
Build       → 90 sec

That's already several minutes.

Now imagine a repository with dozens of packages, the wasted time adds up quickly.

11. Vite+ and GitHub Actions

Vite+ provides an official GitHub Action called setup-vp for installing Vite+ in GitHub Actions. The current repository documentation recommends pinning the action to an exact release or commit rather than using the old floating v1 tag.

A simplified example looks like this:

name: CI

on:
  push:
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: voidzero-dev/setup-vp@<setup-vp-version>
        with:
          node-version: '22'
          cache: true

      - run: vp install
      - run: vp check
      - run: vp test
      - run: vp build

The important part isn't the exact YAML,, it's the workflow:

GitHub Actions
      ↓
   setup-vp
      ↓
   vp install
      ↓
   vp check
      ↓
   vp test
      ↓
   vp build

The same vp commands you use locally can be used in CI. That consistency is valuable.

12. Local Development and CI Use the Same Interface

One thing I particularly like about this approach is that developers don't have to learn a completely different system for CI.

Locally:

vp check
vp test
vp build

CI:

- run: vp check
- run: vp test
- run: vp build

The commands are the same.

That means when something fails in CI, you can often reproduce the same command locally.

For example:

vp test

Instead of trying to understand:

some-custom-ci-script.sh

that internally calls several other tools.

13. A Monorepo Example

Let's imagine a real project.

acme/
├── apps/
│   ├── storefront/
│   └── dashboard/
│
├── packages/
│   ├── ui/
│   ├── auth/
│   ├── api-client/
│   └── utils/
│
├── package.json
└── vite.config.ts

Dependencies might look like:

                 ┌── ui ────────┐
                 │              │
storefront ──────┤              │
                 │              ▼
                 └── api-client
                       │
                       ▼
                     utils

And:

dashboard
    │
    ├── ui
    │
    └── auth
          │
          ▼
        utils

Now imagine you modify:

packages/utils/

Several projects could be affected.

A task runner can use the dependency graph to determine the appropriate execution order.

Instead of manually figuring out:

1. Build utils
2. Build api-client
3. Build ui
4. Build storefront
5. Build auth
6. Build dashboard

you can use the task system to coordinate those tasks.

14. Parallelism

There's another important idea here:

Not every task needs to run sequentially.

Suppose:

storefront
    ↓
   ui

dashboard
    ↓
   auth

The two branches are independent.

Conceptually, they can be processed like this:

          ui ────────> storefront
         /
Start ──
         \
          auth ──────> dashboard

Instead of:

ui
 ↓
storefront
 ↓
auth
 ↓
dashboard

a task system can execute independent work concurrently where appropriate.

This becomes increasingly important as the repository grows.

The goal is simple:

Don't make one task wait for another task if there is no dependency between them.

15. `vp run` Is More Than `npm run`

At first, you might look at:

vp run build

and think:

"Isn't that basically the same as npm run build?"

For a simple project, the difference may not feel dramatic.

But in a monorepo, the task system adds concepts such as:

dependency-aware execution
task graphs
caching
filtering
parallel execution
task-level configuration

So:

npm run build

is primarily: Run this script

Whereas:

vp run build

can be thought of as: Run the appropriate build tasks across the project while understanding their relationships and cached results.

That distinction becomes important at scale.

16. Filtering Tasks

Large monorepos don't always need everything to run.

Sometimes you only want to work with one package.

For example, you might want to run a task for:

apps/storefront

rather than the entire repository.

Vite+ supports filtering in its task workflow, for example:

vp run --filter storefront build

The exact filters you use depend on your workspace structure and task configuration.

The important idea is:

Whole repository
       ↓
     filter
       ↓
Relevant packages
       ↓
Relevant tasks

This is particularly useful when working locally.

17. One Configuration for the Whole Toolchain

We saw in Chapter 3 that Vite+ can use:

vite.config.ts

as a central configuration file.

For a larger repository, that becomes even more useful.

The configuration can include:

import { defineConfig } from 'vite-plus'

export default defineConfig({
  plugins: [],

  test: {
    include: ['src/**/*.test.ts'],
  },

  lint: {
    ignorePatterns: ['dist/**'],
  },

  fmt: {
    semi: true,
    singleQuote: true,
  },

  run: {
    tasks: {
      'generate:icons': {
        command: 'node scripts/generate-icons.js',
      },
    },
  },
})

This means the same configuration surface can describe parts of:

Development
     ↓
Testing
     ↓
Linting
     ↓
Formatting
     ↓
Task execution

The current Vite+ repository documents this unified configuration approach.

18. But Caching Isn't Magic

This is important.

Caching sounds simple:

Nothing changed
    ↓
Use cache

Real projects are more complicated.

A task can read files you didn't expect.

A build can generate files.

A tool can modify something inside node_modules.

Environment variables can affect output.

Generated files can become inputs to another task.

This means cache correctness depends on correctly understanding the task's inputs and outputs.

The Vite+ project has continued improving task-cache reliability, and its release history includes fixes around automatically tracked inputs and caching behavior.

So when introducing caching to a large repository, you should still verify that tasks are configured correctly.

19. Don't Treat Cache Hits as Guaranteed

This is another useful lesson.

You might expect:

vp run build

followed by:

vp run build

to always produce 100% cache hits.

But real-world projects can have tasks that modify their own inputs or produce files that affect the task fingerprint.

The Vite+ issue tracker has documented examples of cache misses caused by generated files and dependency/runtime cache directories.

This doesn't mean caching isn't useful.

It means developers should understand what the cache is actually tracking.

A good mental model is:

Caching is a correctness feature first and a performance feature second.

If the system cannot prove that the previous result is still valid, rerunning the task is safer than incorrectly reusing an old result.

20. A Practical CI Pipeline

For a monorepo, you might eventually have something like:

                 Pull Request
                      │
                      ▼
                 Install deps
                      │
                      ▼
                   vp check
                      │
                      ▼
                   vp test
                      │
                      ▼
                  vp run build
                      │
                      ▼
                Deploy / Publish

The important thing is that developers and CI share the same vocabulary.

Local:

vp check
vp test
vp run build

CI:

- run: vp check
- run: vp test
- run: vp run build

That reduces the gap between:

"It works on my machine."

and:

"Why does CI use completely different commands?"

21. When Does This Actually Matter?

If you're building a small personal website:

1 app
5 components
1 package

you probably won't notice a huge difference.

You can happily use:

vp dev
vp test
vp build

and move on.

But imagine:

10 applications
30 packages
100 developers
hundreds of tasks

Now task execution becomes a real engineering problem.

You care about:

What changed?
What needs rebuilding?
What can run in parallel?
What can use a previous result?
What should CI execute?
How can local and CI workflows stay consistent?

That's the environment where Vite Task and vp run become much more important.

22. The Big Picture

Let's compare the two situations.

Small application

Developer
   │
   ├── vp dev
   ├── vp check
   ├── vp test
   └── vp build

Simple.

Large monorepo

                         Vite+
                           │
                    ┌──────┴──────┐
                    │             │
                  Local           CI
                    │             │
                  vp run        vp run
                    │             │
              ┌─────┴─────┐   ┌──┴───┐
              │           │   │      │
            Tasks      Cache  Tasks  Cache
              │           │   │      │
              └─────┬─────┘   └──┬───┘
                    │             │
                    └──────┬──────┘
                           │
                    Dependency graph

This is where Vite+ starts looking less like:

"A nicer command for Vite."

and more like:

A unified development and task-execution environment for a modern JavaScript repository.

23. Ssummary

In this chapter, we moved from a single application to large repositories, the main concepts were:

Monorepos

Multiple applications and packages living in one repository.

Tasks

Operations such as:

build
test
lint
typecheck

Dependency graphs

Understanding which packages depend on which other packages.

Caching

Reusing previous task results when the relevant inputs haven't changed.

Parallel execution

Running independent tasks at the same time.

CI

Using the same vp workflow locally and in GitHub Actions.

The important command to remember is:

vp run

For a small project, you might barely notice it.

For a large monorepo, it can become one of the most important parts of the Vite+ workflow.

What comes next ?

We've now covered a lot of things, that leaves one big question:

Should you actually use Vite+?

It's easy to get excited about a new toolchain, but every tool has trade-offs.

In next chapter; we'll look at:

When Vite+ makes sense
When it might be unnecessary
Migrating an existing project
The benefits and trade-offs
The beta/early-stage considerations
How to decide whether Vite+ fits your project
What to consider before adopting it in a team

That will bring the series together and give you a practical answer to the question:

"Should I use Vite+?"

Vite+ — Chapter 3: Vite+ in Practice

Othmane Nemli — Fri, 25 Sep 2026 16:33:45 +0000

In the previous chapter, we looked at what Vite+ is made of.

We saw that Vite+ brings together tools such as:

Vite
Vitest
Rolldown
tsdown
Oxlint
Oxfmt
Vite Task

But knowing what these tools are is only half the story.

The more interesting question is:

What does developing a real project with Vite+ actually look like?

That's what we'll explore in this chapter.

We'll create a project, start the development server, run checks and tests, and finally create a production build.

1. Installing Vite+

Vite+ provides a vp command-line interface.

The official beta installation method is different depending on your operating system.

macOS / Linux

curl -fsSL https://vite.plus | bash

Windows

irm https://vite.plus/ps1 | iex

After installation, you can check that the command is available:

vp --version

You should now have access to the vp command.

Think of vp as the main doorway into your JavaScript project.

Instead of remembering which tool should handle each part of your workflow, you can use the same command-line interface.

2. Creating a New Project

Let's create our first Vite+ project.

Run:

# Interactive mode
vp create

Vite+ ships with these built-in templates:

vp vite:monorepo #creates a new monorepo
vp vite:application #creates a new application
vp vite:library #creates a new library

For more examples and options

Vite+ will guide you through creating a project from a template.

Once the project has been created, move into it:

cd my-project

The exact project name depends on what you choose during the creation process.

At this point, you have a project that can use the Vite+ workflow.

3. Installing Dependencies

Normally, JavaScript developers might use:

npm/pnpm/yarn/bun install

Vite+ provides its own entry point for this:

vp install # this command will be executed automatically by vp

Vite+ can work with different package managers and can detect the package-manager setup used by the project.

This is one of the ideas behind Vite+:

You don't necessarily need to change the underlying tools. Vite+ provides a consistent interface over them.

So the goal isn't:

"Everyone must stop using npm."

The goal is closer to:

"Developers shouldn't need to care which command is responsible for every individual part of the workflow."

4. Starting the Development Server

Now let's start developing.

Run:

vp dev

Under the hood, this uses Vite's development server.

You'll get the familiar Vite development experience, including fast module updates when you change your source code.

By default the project comes with a counter componenent

apps/website/src
├── counter.ts
├── main.tsx
└── styles.css

Edit main.tsx:
change "Get started" by "Welcome Vite+" and save the file

Your browser updates without requiring you to manually rebuild the whole application.

That's the Vite experience you already know.

Vite+ doesn't try to replace that experience.

It gives you a consistent command for accessing it:vp dev

5. Checking Your Code

Now let's say you've written some code.

Before committing it, you usually want to check:

Is the code formatted?
Are there lint errors?
Are there type errors?

Traditionally, you might have several commands:

npm run format
npm run lint
npm run typecheck

With Vite+, these checks can be combined:

vp check

The current Vite+ workflow combines formatting, linting, and type checking.

So instead of remembering three different commands, your workflow can become:

vp check

That's a small difference for a small project.

But imagine a team with:

10 developers
20 repositories
several applications
shared packages
CI pipelines
multiple environments

A consistent command becomes much more useful.

More info vp check

6. Running Tests

Let's say we have a test:

import { describe, expect, it } from 'vitest'

describe('addition', () => {
  it('adds two numbers', () => {
    expect(1 + 2).toBe(3)
  })
})

Normally, you might run Vitest directly:

vitest

With Vite+:

vp test

Vite+ runs the tests through Vitest.

Again, notice the pattern:

Development → vp dev
Checks       → vp check
Tests        → vp test

You don't need to memorize which underlying tool powers each command.

You just learn the Vite+ workflow. more info vp test

7. Building for Production

When your application is ready to deploy, you need a production build.

With Vite+, run:

vp build

The application is built for production using Vite and Rolldown.

The important distinction is:

vp dev
   ↓
Development environment

vp build
   ↓
Production build

During development, you want speed and fast feedback.

During production, you want optimized output that can be deployed.

Vite+ gives you a consistent interface for both.

8. Previewing the Production Build

After building the application, you can preview the result with:

vp preview

This lets you check the production build locally before deploying it.

A simple workflow could therefore look like:

vp dev

Develop your application.

Then:

vp check

Check the code.

Then:

vp test

Run the tests.

Finally:

vp build
vp preview

Build and preview the production version.

9. The Workflow Starts to Look Different

At this point, we can summarize the basic workflow:

What you want to do	Vite+ command
Create a project	`vp create`
Install dependencies	`vp install`
Start development	`vp dev`
Check code	`vp check`
Run tests	`vp test`
Build for production	`vp build`
Preview production	`vp preview`

This is where the idea behind Vite+ becomes easier to understand.

It isn't about replacing every individual tool.

It's about creating a consistent interface for the development workflow.

10. What About Existing Projects?

You might be thinking:

"This sounds nice, but I already have a project."

That's an important use case.

Vite+ provides:

vp migrate

This is intended to help migrate an existing project to the Vite+ workflow.

For example, imagine an existing project already has:

my-app/
├── package.json
├── vite.config.ts
├── vitest.config.ts
├── eslint.config.js
├── prettier.config.js
└── src/

Instead of creating everything again, you can run:

vp migrate

Vite+ can bring parts of the existing configuration into its unified setup.

The current migration process shows what it plans to change, but complex projects may still require manual follow-up. The official documentation recommends reviewing the migration guide before using it on a production project.

So migration should not be thought of as:

"Run one command and everything magically changes."

It's better to think of it as:

"Vite+ helps you move an existing project toward the unified workflow."

11. One Configuration File

Another interesting part of Vite+ is configuration.

A Vite+ project can use vite.config.ts as the central configuration point.

For example:

import { defineConfig } from 'vite-plus'

export default defineConfig({
  plugins: [],

  test: {
    include: ['src/**/*.test.ts'],
  },

  lint: {
    ignorePatterns: ['dist/**'],
  },

  fmt: {
    semi: true,
    singleQuote: true,
  },
})

Notice what is happening here.

The same configuration can contain settings for different parts of the development workflow:

vite.config.ts
      │
      ├── Vite
      ├── Vitest
      ├── Oxlint
      ├── Oxfmt
      └── Vite Task

The goal is to reduce the number of separate configuration files you need to understand and maintain. The Vite+ repository documents this unified configuration approach.

For me, I prefer to use separate files, for readability and quick access.

12. And Then There's `vp run`

So far, we've looked at the obvious commands.

But one command becomes especially interesting when a project grows:

vp run

vp run can execute package.json scripts and Vite Task workflows, including dependency-aware task execution and caching.

Imagine a monorepo:

my-company/
├── apps/
│   ├── web/
│   └── admin/
│
└── packages/
    ├── ui/
    ├── utils/
    └── config/

Now imagine:

web
 ↓
ui
 ↓
utils

If utils changes, some tasks need to run again.

But if nothing relevant changed, running everything again wastes time.

This is where task caching becomes useful.

For example:

vp run build

Vite+ can understand task relationships and reuse cached results where appropriate.

That's much more interesting in large repositories than in a tiny demo application.

And that leads directly into the next stage of our series.

Note:

vpr is available as a standalone shorthand for vp run.

13. A Realistic Daily Workflow

After everything we've seen, a developer's day might look something like this:

Start working

vp dev

Make changes

Write your application code.

Check everything

vp check

Run tests

vp test

Build before deployment

vp build

Preview the result

vp preview

The commands are simple.

That's intentional.

The complexity is moved away from remembering dozens of unrelated commands and toward having one consistent toolchain.

14. The Bigger Picture

Let's step back for a moment.

Without a unified workflow, you might have something like:

npm
 │
 ├── Vite
 ├── Vitest
 ├── ESLint
 ├── Prettier
 ├── TypeScript
 ├── task runner
 └── package scripts

With Vite+:

                 Vite+
                   │
       ┌───────────┼───────────┐
       │           │           │
     Build       Test        Check
       │           │           │
     Vite       Vitest     Oxlint/Oxfmt
       │
    Rolldown

The underlying technologies are still there.

What's different is the way you interact with them.

Instead of thinking:

"Which tool handles this?"

you can increasingly think:

"Which vp command handles this?"

That's the central idea of Vite+ in practice.

What's Next?

In Chapter 4, we'll move beyond a single application.

We'll look at Vite+ at scale:

Monorepos
Task dependencies
Caching
Parallel execution
CI/CD
Shared configuration
Why vp run becomes much more valuable as a repository grows

That's where Vite+ starts solving problems that are difficult to see in a small project.

Vite+ — Chapter 2: What’s Inside Vite+?

Othmane Nemli — Fri, 25 Sep 2026 15:09:36 +0000

In the first chapter, we looked at why Vite+ exists.

The short version was:

Modern JavaScript projects use many excellent tools, but connecting and maintaining all those tools can become complicated.

Vite+ tries to bring several of those tools together behind one workflow.

But this raises another question:

What is actually inside Vite+?

If you see:

vp dev
vp test
vp check
vp build

what happens behind those commands?

Let's open the toolbox.

Vite+ is not one giant tool

The first thing to understand is that Vite+ isn't a single replacement for everything.

It brings together several tools, each with a specific job.

A simplified view looks like this:

                    Vite+
                      |
       +--------------+--------------+
       |              |              |
   Development      Quality        Testing
       |              |              |
      Vite       Oxlint / Oxfmt   Vitest
       |
    Building
       |
   Rolldown

       +-----------------------------+
       |
    Libraries
       |
    tsdown

       +-----------------------------+
       |
     Tasks
       |
   Vite Task

Each tool solves a different problem.

The important part is that Vite+ gives you a consistent way to work with them.

Let's go through them one by one.

1. Vite — Development

Let's start with the tool most developers already know.

Vite is primarily a development server and build tool.

If you're building a React application, for example, you might have:

src/
├── App.tsx
├── main.tsx
└── components/
    └── Button.tsx

You want to write code and immediately see the result in your browser.

That's where Vite comes in.

You can start your development server with:

vp dev

Under the hood, Vite is doing the work.

Why is Vite useful?

Imagine you change:

function Button() {
  return <button>Hello</button>;
}

to:

function Button() {
  return <button>Hello World</button>;
}

You don't want to stop the server, rebuild the entire application, and restart the browser every time you change a line.

Vite provides a fast development experience with features such as Hot Module Replacement (HMR).

In simple terms:

You change code
      ↓
Vite notices
      ↓
Browser updates
      ↓
You keep working

This is why Vite has become such a common part of modern frontend development.

With Vite+, you still get Vite.

Vite+ doesn't replace it.

2. Vitest — Testing

Writing code is only half of the job.

We also need to make sure it works.

That's where Vitest comes in.

Suppose you have this function:

function add(a: number, b: number) {
  return a + b;
}

You could write a test:

import { expect, test } from "vitest";

test("adds two numbers", () => {
  expect(add(2, 3)).toBe(5);
});

Then run:

vp test

Vite+ uses Vitest as its testing tool.

Why Vitest instead of something else?

You might already know tools such as Jest.

The important thing here isn't to decide which test runner is "the best."

The interesting part is that Vitest works very naturally with the Vite ecosystem.

That means your development and testing environments can share much of the same configuration and behavior.

Conceptually:

Development
     ↓
   Vite

Testing
     ↓
  Vitest

        ↓
Shared ecosystem

This integration is one of the reasons Vitest fits naturally into Vite+.

3. Rolldown — Bundling

Now we get to a term that can sound intimidating:

bundler.

Don't worry. The idea is simple.

Your application might contain hundreds or thousands of files:

src/
├── main.ts
├── App.tsx
├── components/
│   ├── Button.tsx
│   ├── Modal.tsx
│   └── Header.tsx
├── utils/
│   ├── date.ts
│   └── format.ts
└── ...

The browser doesn't necessarily need to receive all those files exactly as they exist in your source code.

A bundler analyzes the relationships between your files and produces optimized output for production.

Conceptually:

Your source code
       ↓
    Bundler
       ↓
Production files
       ↓
     Browser

Traditionally, Vite has used Rollup for production builds.

Vite+ includes Rolldown, a newer bundler written in Rust and designed to provide a high-performance bundling foundation for the Vite ecosystem.

You don't necessarily need to interact with Rolldown directly.

You can simply run:

vp build

and let the toolchain handle it.

Why does a bundler matter?

Imagine your application has:

10,000 lines of source code

You don't want to manually decide:

"Which files should be included?"

"Which modules depend on each other?"

"Can these files be combined?"

"Can unused code be removed?"

The bundler handles these kinds of problems.

It builds a dependency graph:

App
├── Header
├── Dashboard
│   ├── Chart
│   └── Table
└── Utils

Then it can produce optimized output.

This is one of the areas where build performance becomes important, especially for large projects.

4. tsdown — Building libraries

Applications aren't the only thing developers build.

Sometimes you're creating a library.

For example:

my-ui-library
my-auth-library
my-api-client
my-utils

Suppose you have:

export function formatDate(date: Date) {
  // ...
}

You want other developers to install your package:

npm install my-utils

Now your build process has different requirements.

You may need:

JavaScript output
TypeScript declarations
different module formats
package metadata
optimized output

This is where tsdown comes into the Vite+ ecosystem.

You can use:

vp pack

to package a library.

The important distinction is:

Application
    ↓
vp build

Library
    ↓
vp pack

The two workflows have different goals.

5. Oxlint — Linting

Now let's talk about code quality.

Imagine someone writes:

const user = getUser();

console.log(user);

if (user) {
  // ...
}

The code might work.

But there may be problems:

unused variables
suspicious patterns
accidental bugs
inconsistent code
practices your team doesn't allow

A linter looks for these kinds of issues.

Vite+ uses Oxlint for linting.

You can think of it as:

Your code
   ↓
Oxlint
   ↓
Potential problems

For example:

vp check

can include linting as part of the overall project check.

Why another linter?

You might be thinking:

"But we already have ESLint."

Yes.

ESLint is still widely used and has a huge ecosystem.

Oxlint takes a different approach and focuses heavily on performance.

It is part of the broader Oxc toolchain and is written in Rust.

For Vite+, the important idea is not:

"ESLint is bad."

It's:

"What if common development tooling could be extremely fast and integrated into one toolchain?"

That's the philosophy behind choosing tools such as Oxlint.

6. Oxfmt — Formatting

Linting and formatting are related, but they aren't the same thing.

A linter asks:

"Is there something potentially wrong with this code?"

A formatter asks:

"Can we make the code follow a consistent style?"

For example, these are functionally similar:

const user={name:"John"};

and:

const user = {
  name: "John",
};

But most teams want everyone to use the same formatting rules.

That's where Oxfmt comes in.

You can think of it as the formatting part of the workflow:

Source code
    ↓
Oxfmt
    ↓
Consistent formatting

Again, this is similar to what developers have traditionally used Prettier for.

Linting vs formatting

If you're new to frontend development, this distinction is worth remembering.

Formatting

"Make the code look consistent."

Example:

const name="John"

becomes:

const name = "John";

Linting

"Look for patterns that might be problematic."

For example:

const unusedVariable = 123;

A linter can tell you:

unusedVariable is never used

So:

Oxfmt  → How the code looks

Oxlint → Potential problems in the code

Both can be part of:

vp check

7. Vite Task — Running tasks

Now we get to a part that becomes more interesting as your project grows.

Most projects have tasks.

For example:

build
test
lint
typecheck

You might define them in package.json:

{
  "scripts": {
    "build": "...",
    "test": "...",
    "lint": "..."
  }
}

For a small project, that's enough.

But imagine a monorepo with:

apps/
  web/
  admin/

packages/
  ui/
  auth/
  utils/

Now tasks have relationships.

For example:

ui
 ↓
web

If the UI package changes, the web application may need to be rebuilt.

This is where a task runner becomes useful.

Vite+ includes Vite Task for task execution and caching.

Task dependencies

Let's make this concrete.

Imagine:

packages/ui

is used by:

apps/web

You change:

packages/ui/Button.tsx

The dependency graph is:

ui
 ↓
web

A smart task runner can understand:

"The web application depends on UI, so the web build may need to run."

But suppose another package didn't change:

packages/utils

If nothing relevant changed there, rebuilding everything may be unnecessary.

That's where task graphs and caching become useful.

Caching

Caching sounds complicated, but the basic idea is very simple.

Imagine you run:

vp run build

The build takes:

30 seconds

You run it again without changing anything.

Why should you spend another 30 seconds doing exactly the same work?

A cache can remember the previous result.

Conceptually:

First run:

Source
  ↓
Build
  ↓
Result
  ↓
Cache

Then:

Second run:

Source
  ↓
Anything relevant changed?
  ↓
No
  ↓
Reuse result

This becomes particularly valuable in large repositories and CI.

We'll go much deeper into this in Chapter 4.

8. Runtime and package management

There's another part of the developer experience that is easy to overlook:

the environment itself.

A project might expect:

Node.js 22
pnpm

while another project expects:

Node.js 20
npm

Vite+ also provides commands and workflows for managing the runtime and package manager environment.

For example:

vp env

can be used as part of this workflow.

The goal is to make the environment used by the project more explicit and reproducible.

This matters because:

"Works on my machine."

is one of the oldest problems in software development.

Putting the pieces together

Now we can see what sits behind the simple vp command.

                         Vite+
                           |
        +------------------+------------------+
        |                  |                  |
    Development         Quality            Testing
        |                  |                  |
       Vite         Oxlint + Oxfmt         Vitest
        |
     Building
        |
    Rolldown

        |
    Libraries
        |
     tsdown

        |
      Tasks
        |
   Vite Task

Instead of learning every tool separately on day one, you can interact with them through a common workflow.

For example:

vp dev

→ development

vp test

→ testing

vp check

→ code quality

vp build

→ production build

vp pack

→ library packaging

vp run

→ project tasks

But should you care which tool is underneath?

Yes.

Even though Vite+ gives you a unified interface, you shouldn't treat it as magic.

If something goes wrong with your tests, knowing that Vite+ uses Vitest helps you investigate.

If your build has an issue, understanding Vite and Rolldown helps.

If linting reports something unexpected, knowing that Oxlint is involved gives you a direction for debugging.

This is especially important for senior developers.

A good abstraction hides unnecessary complexity.

It shouldn't hide useful knowledge.

The important mental model

Don't think:

Vite+ = one giant replacement for everything

Think:

Vite+ = an integrated workflow

             ↓

     +-------+-------+
     |       |       |
    Vite   Vitest  Oxlint
     |       |       |
 Rolldown  Tests   Oxfmt
     |
   tsdown
     |
 Vite Task

Each component has a job.

Vite+ connects those components.

What we've learned

At this point, you don't need to remember every detail.

Just remember this:

Tool	Simple explanation
Vite	Develop and build web applications
Vitest	Test your code
Rolldown	Bundle your application
tsdown	Package libraries
Oxlint	Find potential code problems
Oxfmt	Format your code
Vite Task	Run tasks and reuse cached results

And Vite+ provides the common workflow around them.

One last question

Now that we know what's inside Vite+, there's still a practical question:

What does using it actually feel like?

It's one thing to read:

vp dev
vp test
vp check
vp build

It's another thing to create a project and use those commands yourself.

So in the next chapter, we'll stop talking about the pieces individually.

We'll build something.

We'll look at:

Create a project
      ↓
Install dependencies
      ↓
Start development
      ↓
Write code
      ↓
Run tests
      ↓
Check the project
      ↓
Build for production

That's where Vite+ starts becoming something you can actually use rather than just something you understand.

Next chapter: Vite+ in Practice — From Your First Project to Production

Vite+ — Chapter 1: Why Do We Need Another JavaScript Tool?

Othmane Nemli — Thu, 24 Sep 2026 10:53:45 +0000

If you've worked with modern JavaScript projects, you've probably seen a package.json that looks something like this:

{
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "test": "vitest",
    "lint": "oxlint",
    "format": "oxfmt",
    "typecheck": "tsc --noEmit"
  }
}

At first, this doesn't look complicated.

You have a command for development, one for building, one for testing, and a few for keeping the code clean.

But there's something hiding behind these commands.

Your project is now depending on several different tools, configurations, versions, and conventions.

And that's the problem Vite+ is trying to address.

The JavaScript toolchain keeps growing

Let's say you're starting a new TypeScript application.

You might begin with:

TypeScript
Vite

Then you want tests:

TypeScript
Vite
Vitest

You add linting:

TypeScript
Vite
Vitest
Oxlint

Then formatting:

TypeScript
Vite
Vitest
Oxlint
Oxfmt

Then perhaps you have a monorepo:

apps/
  web/
  admin/

packages/
  ui/
  utils/

Now you also need to think about:

How should packages depend on each other?
Which tasks need to run first?
Can some tasks run in parallel?
Can completed tasks be cached?
What should CI run?
Which Node.js version should everyone use?
Which package manager should the repository use?

None of these problems are particularly new.

But together, they create something we don't always talk about:

toolchain complexity.

The tools aren't the problem

This is important.

Vite isn't the problem.

Vitest isn't the problem.

Oxlint isn't the problem.

Your package manager isn't the problem.

In fact, these tools exist because they solve real problems.

The issue is that we have to connect them ourselves.

Think about a typical development workflow:

Development
    ↓
Vite

Testing
    ↓
Vitest

Linting
    ↓
Oxlint

Formatting
    ↓
Oxfmt

Building
    ↓
Vite / Rolldown

Library packaging
    ↓
tsdown

Tasks
    ↓
Task runner

Runtime + packages
    ↓
Node + npm/pnpm/Yarn/Bun

Each piece makes sense on its own.

But someone has to make the whole thing work together.

That "someone" is usually the development team.

What happens when the project grows?

Imagine a small team with five developers.

The project is simple.

Everyone knows:

npm run dev
npm run test
npm run lint

No big deal.

Now the team grows.

The project becomes a monorepo.

You have multiple applications and shared packages:

my-company/
├── apps/
│   ├── web/
│   └── admin/
│
└── packages/
    ├── ui/
    ├── auth/
    └── utils/

Now running everything becomes more complicated.

Maybe web depends on ui.

ui
 ↓
web

If ui changes, web may need to be rebuilt.

But if auth didn't change, why should everything related to auth run again?

Now you're thinking about:

task dependencies
caching
parallel execution
CI performance

This is where the development toolchain starts becoming a project of its own.

And then there's CI

Your local machine might run:

npm run test
npm run lint
npm run build

But your CI pipeline needs to do the same thing.

So now you have another layer of configuration.

Your repository might contain:

package.json
vite.config.ts
vitest.config.ts
eslint.config.js
prettier.config.js
.github/workflows/...

Again, this is perfectly normal.

But every additional configuration file is another thing developers need to understand and maintain.

And sometimes your local environment and CI don't behave exactly the same.

Maybe:

Local:
Node 22

CI:
Node 20

Or perhaps developers use pnpm while another repository uses npm.

The tools themselves aren't necessarily difficult.

The integration is.

So, what is Vite+?

This is where Vite+ comes in.

Vite+ is designed as a unified toolchain for web development.

Instead of assembling your development environment piece by piece, Vite+ brings several tools together behind a single vp command.

For example:

vp dev

starts development.

vp test

runs tests.

vp check

runs formatting, linting, and type checking.

vp build

builds the project.

And:

vp run

handles project tasks, including dependency-aware execution and caching.

The goal is not simply to give you shorter commands.

The bigger idea is:

Give developers one consistent workflow for the things they do every day.

Is Vite+ just a new Vite?

No.

This is probably the most important thing to understand before continuing.

Vite and Vite+ are different things.

Vite is primarily a development server and build tool.

Vite+ is a broader toolchain that brings together several technologies, including:

Vite
Vitest
Rolldown
tsdown
Oxlint
Oxfmt
Vite Task

It also manages runtime and package-manager workflows.

You can think about it like this:

Vite
  ↓
Development + application build


Vite+
  ↓
Development
Testing
Linting
Formatting
Building
Library packaging
Task execution
Caching
Runtime/package management

So Vite+ isn't replacing Vite.

It is building a larger workflow around it.

Why not just keep using separate tools?

That's a completely reasonable question.

And honestly, you might not need Vite+.

If your project is small, stable, and your team is happy with its current setup, there may be little reason to change it.

The interesting question is what happens when you have to maintain this setup across many projects.

Imagine having:

Project A
  Vite
  Vitest
  ESLint
  Prettier

Project B
  Vite
  Jest
  ESLint
  Prettier

Project C
  Vite
  Vitest
  Oxlint
  Oxfmt
  Turborepo

Now developers need to remember different commands and different conventions depending on the repository.

Vite+ is trying to reduce that variation.

Its documentation describes the goal as avoiding the need for developers to repeatedly assemble their toolchain by hand and giving teams a more consistent setup across projects.

A simple mental model

Here's the easiest way I currently think about Vite+:

Without Vite+:

        You
         |
   ----------------
   |   |   |   |  |
  Vite Vitest Lint Format ...
   |   |   |   |
   -----------+----
              |
         Your scripts

With Vite+:

        You
         |
       vp
         |
   -----------------
   |   |   |   |   |
 Vite Test Lint Format
         |
      Tasks

The tools are still there.

The difference is who is responsible for connecting them.

Why does this matter to a developer?

Because developers should ideally spend their time solving product problems, not repeatedly solving tooling problems.

You don't want your morning to start with:

"Why is the formatter using a different version on CI?"

Or:

"Which command do I need to run before opening a PR?"

Or:

"Why did this package rebuild when nothing changed?"

Or:

"How do I set up this repository on a new machine?"

These are small problems.

But small problems repeated across dozens of developers and hundreds of builds become expensive.

Vite+ is trying to make these workflows more predictable.

What does Vite+ actually change?

The easiest way to understand the difference is through commands.

A Vite+ project can have a workflow like:

vp dev

Develop

vp check

Check the code

vp test

Run tests

vp build

Build for production

vp run

Run project tasks

vp pack

Package a library

These commands are backed by different tools, but they share a common interface.

That consistency is the real feature.

But isn't this just hiding the complexity?

To some extent, yes.

And that's not necessarily a bad thing.

Think about Git.

You can use:

git commit

without understanding every internal detail of Git's object database.

Or you can use Docker without understanding every detail of Linux namespaces.

Good developer tools often provide a simple interface while allowing you to go deeper when necessary.

Vite+ follows a similar idea.

A junior developer can start with:

vp dev
vp test
vp check

while a senior developer can investigate what is actually happening underneath.

And that's exactly what the next articles in this series will do.

The bigger idea

The interesting thing about Vite+ isn't the vp command itself.

It's the philosophy behind it.

Modern web development has become incredibly powerful, but also increasingly fragmented.

We have excellent tools for almost everything:

Development → Vite
Testing → Vitest
Bundling → Rolldown
Libraries → tsdown
Linting → Oxlint
Formatting → Oxfmt
Tasks → Vite Task

The challenge is making all of these tools behave like one development workflow.

That's what Vite+ is attempting to provide.

The official announcement describes it as a single entry point to web development, combining these tools into one tested stack while remaining compatible with the broader Vite ecosystem.

One important detail: Vite+ is still evolving

At the time of writing, Vite+ is in beta.

The project describes it as stable but not yet complete, with additional work planned toward 1.0, including remote caching, broader framework/plugin compatibility, more migration targets, and improvements to documentation and diagnostics.

So this series isn't about saying:

"Everyone should replace their current setup with Vite+."

Instead, the goal is to understand what it is, what problem it solves, and where it makes sense.

Once you understand that, you can decide whether it is useful for your project.

What's next?

Now that we understand why Vite+ exists, let's open the toolbox.

In the next chapter, we'll look at the individual pieces:

Vite
Vitest
Rolldown
tsdown
Oxlint
Oxfmt
Vite Task

What does each one do?

Why do we need it?

And how does it fit into Vite+?

That's where things start getting more interesting.

Next chapter: Vite+ From the Inside — Understanding the Tools Behind vp

Laravel's New whereBinary(): Simple Case-Sensitive Queries in MySQL

Othmane Nemli — Tue, 22 Sep 2026 15:54:57 +0000

If you have worked with Laravel and MySQL for a while, you have probably run into this situation:

User::where('name', 'john')->get();

You expect this to find only:

john

But depending on your MySQL collation, it may also match:

John
JOHN
JoHn

This happens because many MySQL string comparisons are case-insensitive by default.

Laravel 13.x now has a small but useful addition to the Query Builder:

whereBinary()

It gives us a clean way to tell the database:

"Compare this value exactly, using a binary comparison."

The feature was added in Laravel framework PR #61261. It also adds whereNotBinary(), orWhereBinary(), and orWhereNotBinary().

Let's see how it works.

The problem: normal string comparisons.

Imagine we have a users table:

id | name
---|------
1  | John
2  | john
3  | JOHN
4  | Alice

Now we run:

$users = DB::table('users')
->where('name', 'john')
->get();

Depending on the column's collation, MySQL may consider these values equal:

John
john
JOHN

So our query can return more records than we expected.

This isn't a Laravel problem, it's how MySQL string comparison works with a case-insensitive collation.

The old Laravel solution

Before whereBinary(), you could write a raw expression:

$users = DB::table('users')
->whereRaw('name = BINARY ?', ['john'])
->get();

This works, but it isn't particularly nice.

You're mixing Laravel's query builder with database-specific SQL.

You might also have seen code like this:

DB::table('users')
->where('name', '=', DB::raw('BINARY "john"'))
->get();

Again, it works, but it's not very expressive.

Laravel's new method makes the intention much clearer.

Meet `whereBinary()`

Now we can simply write:

$users = DB::table('users')
->whereBinary('name', 'john')
->get();

That's much easier to read.

The meaning is:

Find users where name is exactly john, using a binary comparison.

For MySQL, Laravel generates SQL equivalent to:

select *
from `users`
where `name` = binary ?

with john passed as a bound parameter.

This is exactly what the new Laravel tests verify.

What does "binary" actually mean?

This is the important part.

A normal comparison might treat:

john
John
JOHN

as equal.

A binary comparison cares about the actual characters.

So:

john != John
john != JOHN
John != JOHN

But:

john == john

For example:

DB::table('users')
->whereBinary('name', 'john')
->get();

could match:

john

but not:

John
JOHN
JoHn

This is particularly useful when the exact casing matters.

`whereNotBinary()`

The PR also adds the opposite operation:

whereNotBinary()

For example:

$users = DB::table('users')
->whereNotBinary('name', 'john')
->get();

This means:

Find rows where name is not exactly john.

Laravel generates:

where `name` != binary ?

So if the database contains:

john
John
JOHN
Alice

whereNotBinary('name', 'john') can match:

John
JOHN
Alice

but not:

john

`orWhereBinary()`

You can also use the binary comparison with OR.

For example:

$users = DB::table('users')
->where('id', 1)
->orWhereBinary('name', 'john')
->get();

This produces the equivalent of:

select *
from `users`
where `id` = ?
or `name` = binary ?

This is useful when you want to combine a normal condition with a case-sensitive condition.

`orWhereNotBinary()`

And, of course, there is also:

orWhereNotBinary()

For example:

$users = DB::table('users')
->where('id', 1)
->orWhereNotBinary('name', 'john')
->get();

The generated condition is equivalent to:

where `id` = ?
or `name` != binary ?

So we now have four methods:

Method	Meaning
`whereBinary()`	Exact binary equality
`whereNotBinary()`	Not exactly equal
`orWhereBinary()`	Binary equality using `OR`
`orWhereNotBinary()`	Binary inequality using `OR`

An example with usernames

This is probably one of the easiest real-world examples.

Imagine your application has usernames:

john
John
john123
John123

If your application treats usernames as case-sensitive, you might want:

$user = DB::table('users')
->whereBinary('username', 'John')
->first();

Now you're explicitly asking the database for the exact value:

John

rather than relying on whatever collation happens to be configured on the column.

An example with API keys

Another possible use case is comparing values where the exact string matters.

For example:

$key = DB::table('api_keys')
->whereBinary('key', $providedKey)
->first();

The comparison is binary rather than a normal case-insensitive string comparison.

However, don't confuse this with password hashing or password security.

You should still store passwords using a proper password hashing algorithm such as Laravel's password hashing facilities.

whereBinary() is about database string comparison, not password security.

It also works with Eloquent

Because Eloquent uses Laravel's query builder underneath, you can use the method in an Eloquent query as well:

$user = User::query()
->whereBinary('name', 'john')
->first();

And:

$users = User::query()
->whereNotBinary('name', 'john')
->get();

This makes it convenient when you're already working with models.

What happens behind the scenes?

The implementation is actually quite small.

Laravel adds a new Binary where type to the query builder.

Conceptually, this:

->whereBinary('name', 'john')

gets stored as a binary where condition.

The MySQL grammar then turns it into:

`name` = binary ?

For whereNotBinary() it becomes:

`name` != binary ?

The value is still passed as a normal query binding, so you don't need to manually put the value into a raw SQL string.

This is one of the nice things about the new API: you get the database-specific comparison without having to write the raw SQL yourself.

What about PostgreSQL and SQLite?

This is an important detail.

This new feature is not pretending that every database supports the same binary comparison syntax.

The base Laravel grammar throws an exception if the database grammar doesn't support binary comparisons.

The tests in the PR explicitly verify this behavior for PostgreSQL, SQLite, and SQL Server.

MySQL and MariaDB, on the other hand, compile the condition using:

= binary

or:

!= binary

So if your application uses MySQL or MariaDB, this feature is directly relevant.

If your application supports multiple database engines, keep this database-specific behavior in mind.

When should you use `whereBinary()`?

A good rule is:

Use it when the exact characters matter.

For example:

->whereBinary('username', $username)

when usernames are case-sensitive.

Or:

->whereBinary('code', $code)

when a code should match exactly.

Or:

->whereBinary('slug', $slug)

if your application intentionally treats slug casing as significant.

When should you NOT use it?

Don't automatically replace every where() with whereBinary().

For example, if you want a normal user search:

User::where('name', 'john')->get();

you may actually want:

John
john
JOHN

to be considered the same.

In that situation, a case-insensitive comparison is useful.

The important thing is to decide what your application means by "equal".

One small API, one useful problem solved

The new API isn't a huge change.

That's actually what makes it nice.

Instead of writing:

->whereRaw('name = BINARY ?', [$name])

you can now write:

->whereBinary('name', $name)

And instead of:

->whereRaw('name != BINARY ?', [$name])

you can write:

->whereNotBinary('name', $name)

Your intent becomes much easier to understand when reading the code.

The complete example

Here's a simple example showing all four methods:

// Exact binary match
User::whereBinary('name', 'john')->get();

// Exact binary non-match
User::whereNotBinary('name', 'john')->get();

// Binary match with OR
User::where('active', true)
->orWhereBinary('name', 'john')
->get();

// Binary non-match with OR
User::where('active', true)
->orWhereNotBinary('name', 'john')
->get();

Summay

whereBinary() is a small addition, but it solves a common source of confusion when working with MySQL and case-sensitive values.

The biggest benefit isn't that it makes something possible that you couldn't do before. You could already use BINARY through raw SQL.

The benefit is that Laravel now gives us a clear query-builder API for saying:

whereBinary('name', 'john')

instead of having to drop down into:

whereRaw('name = BINARY ?', ['john'])

If you're using MySQL or MariaDB and you need an exact, case-sensitive string comparison, whereBinary() is a much cleaner way to express that intent.

Laravel WhereHas() and With()

Othmane Nemli — Tue, 06 Jul 2021 09:44:58 +0000

Updates:

June 2022 Laravel merged a PR (a year later from this topic) to Laravel 9, that add a new eloquent withWhereHas() -- doc

This Topic now only for Legacy projects (before Laravel 9).

Quick recall:

When accessing Eloquent relationships as properties, the related models are "lazy loaded". This means the relationship data is not actually loaded until you first access the property. However, Eloquent can "eager load" relationships at the time you query the parent model. Eager loading alleviates the "N+1" query problem. To illustrate the *N+1 *query problem, consider a Book model that "belongs to" to an Author model:

<?php
namespace App;
use Illuminate\Database\Eloquent\Model;
class Book extends Model
{
 /**
 * Get the author that wrote the book.
 */
 public function author()
 {
 return $this->belongsTo(Author::class);
 }
}

We can use eager loading to reduce this operation to just two queries. When building a query, you may specify which relationships should be eager loaded using the with() method:

$books = Book::with('author')->get();
foreach ($books as $book) {
 echo $book->author->name;
}

Query Results:

select * from books
select * from authors where id in (1, 2, 3, 4, 5, …)

When retrieving model records, you may wish to limit your results based on the existence of a relationship. For example, imagine you want to retrieve all authors that have books' titles start with PHP. To do so, you may pass the name of the relationship to the whereHas() method and define additional query constraints on your has queries

$authors = Author::whereHas('books', function (Builder $query) {
 $query->where('title', 'like', 'PHP%');
})->get();

Query Result:

select * from authors WHERE EXISTS(SELECT * FROM authors WHERE authors.id = books.author_id and books.title like 'PHP%');

When this query gets executed you get all authors who have at least one book start with PHP, correct? Yes.
Now If you loop over the authors and access the book relationship like so,

foreach ($authors as $author) {
 echo $author->book->title;
}

You will end up with N+1, and to solve it sure you will use with() method to eager load books:

$authors = Author::with('books')
 ->whereHas('books', function (Builder $query) {
 $query->where('title', 'like', 'PHP%');
 })
 ->get();

Query Result:

select * from authors WHERE EXISTS(SELECT * FROM authors WHERE authors.id = books.author_id and books.title like 'PHP%');
select * from books where `books`.`author_id` in (1, 5, 11, 22, 46, 62, ….)

So far so good, we solve N+1 issue, but WAIT did you notice something, well I do, the 2nd query gets all books from only the authors that selected from the 1st query, right? Yes.
Our first query did its job and gets us only authors that have books that start with PHP, but the 2nd query (eager load) will get us all books for each author, that means if I looped over the authors and call book relationship we will see also other books not only those start with PHP.

[
 App\Author : {
 id: 1
 name: "author 1",
 …,
 books: [
 App\Books: {
 ….
 title: 'PHP'
 },
 App\Books: {
 ….
 title: 'Java'
 },
 App\Books: {
 ….
 title: 'How to use'
 },
 …
 ]
 }
 …
]

to get same results as we wanted from whereHas we need to use same condition query inside with() method.

$authors = Author::with(['books' => fn($query) => $query->where('title', 'like', 'PHP%')])
 ->whereHas('books', fn ($query) => 
 $query->where('title', 'like', 'PHP%')
 )
 ->get();

Query Results:

select * from authors WHERE EXISTS(SELECT * FROM authors WHERE authors.id = books.author_id and books.title like 'PHP%');
select * from books where `books`.`author_id` in (1, 5, 11, 22, 25, 27, 35, 39, 46, 62, ….) and books.title like 'PHP%');

I think you have already noticed the 2nd query has the same condition as 1st query.
Now, these are the results that we are looking for become:

[
 App\Author : {
 id: 1
 name: "author 1",
 …,
 books: [
 App\Books: {
 ….
 title: 'PHP'
 },
 …
 ]
 },
 App\Author : {
 id: 2
 name: "author 2",
 …,
 books: [
 App\Books: {
 ….
 title: 'PHP'
 },
 App\Books: {
 ….
 title: 'PHP Laravel'
 },
 …
 ]
 }
 …
]

- - - - - -
Finally, doing this query over all places and repeating the same conditions, is cumbersome, so we will use a local scope in Author model

public function scopeWithWhereHas($query, $relation, $constraint){
 return $query->whereHas($relation, $constraint)
 ->with([$relation => $constraint]);
}

Now, our code is much cleaner by calling it this way:

Author::withWhereHas('books', fn($query) =>
 $query->where('title', 'like', 'PHP%')
)->get();

Query Results:

select * from authors WHERE EXISTS(SELECT * FROM authors WHERE authors.id = books.author_id and books.title like 'PHP%');
select * from books where `books`.`author_id` in (1, 5, 11, 22, 25, 27, 35, 39, 46, 62, ….) and books.title like 'PHP%');

Since this query builder may be needed in many Models we will create a macro for it so all Models will have that scope, all you need is to add this snippet under *AppServiceProvider::boot() *

use Illuminate\Database\Eloquent\Builder;

Builder::macro('withWhereHas', fn($relation, $constraint) =>
 $this->whereHas($relation, $constraint)->with([$relation => $constraint]);
);

Well, you reach the end of this topic, I hope all is clear and if you have any similar thoughts or ideas, I would be happy if you share them with us.
Thank you

Different ways to use Laravel Form Requests

Othmane Nemli — Tue, 29 Jun 2021 11:25:18 +0000

Laravel provides several different approaches to validate your application’s incoming data. It is most common to use the validate method available on all incoming HTTP requests. However, in this topic, we will use Form Requests in different ways.

First of all, I don’t think using a small validation in the controller will harm your code readability but on the other hand, if you are willing to handle more complex validation scenarios, you may wish to create a “Form Request“.

Form requests are custom request classes that encapsulate their own validation and authorization logic.

Let’s create our own form request class, all you need is to run this command:

php artisan make:request StoreUserRequest

A new StoreUserRequest class will be generated under "\App\Http\Requests" namespace containing a rules() & authorize() methods.
Let’s add some quick validation under rules() method

/**
 * Get the validation rules that apply to the request.
 *
 * @return array
 */
public function rules()
{
    return [
        'name' => 'required|min:3|max:50',
        'email' => 'required|email|unique:users',
        'password' => 'required|confirmed|min:8',
        //... more validation
    ];
}

After that, we will inject our new Form request in the controller store() method

/**
 * Store a new user.
 *
 * @param  \App\Http\Requests\StoreUserRequest  $request
 * @return Illuminate\Http\Response
 */
public function store(StoreUserRequest $request)
{
    // The incoming request is valid...

    // Retrieve the validated input data...
    $validatedData = $request->validated();
}

So far so good, if the validation is valid we will get our validated data from Form request otherwise a Validation Exception will be thrown.

Now, what about the update, clearly we need to use another form request UpdateUserRequest with its rules and inject it in the controller update() method.

So this is the first and the simple approach used so far.

The second approach is using one class to handle the store and update rules, so, we will run the command again and create new Form Request by naming it UserRequest.

We create store() and update() functions and call them in rules() function by using isMethod() we're checking the HTTP request method if is it a POST or other than that, you may be specific and check if it is a PUT/PATCH.

As you may notice we can also share validations used in both methods and concatenate it with the proper validation function.

public function rules()
{
 return ['name' => 'required|min:3|max:50']
 +
 ($this->isMethod('POST') ? $this->store() : $this->update());
}

protected function store()
{
 return [
 'email' => 'required|email|unique:users',
 'password' => 'required|confirmed|min:8',
 //… more validation

 ];
}

protected function update()
{
 return [
 'email' => 'required|email|unique:users,email,'.$this->user()->id,
 'logo' => 'nullable|image|max:1024',
 'bio' => 'nullable|max:300',
 'github_url' => 'nullable|url'
 //… more validation

 ];
}

After that, we will inject UserRequest in both store() and update() methods.
Now, we have one class that serve different validation depends on HTTP request.

/**
 * Store a new user.
 */
public function store(UserRequest $request)
{
 $validated = $request->validated();
}
/**
 * Update user.
 */
public function update(UserRequest $request)
{
 $validated = $request->validated();
}

I will name the third approach “ResourceFormRequest” and it will be a little bit different from the others.

First I’ll create a BaseFormRequest that contains all resourceful methods, feel free to use your own naming just be careful when you name your methods to not end up overriding Request class methods.

After that, create UserRequest and extends BaseFormRequest, and override existing methods with your rules, finally inject the UserRequest inside your controller methods.

Our Resource Form Request can handle now a Controller resource and you end up with one file that manage all validations of specific Model instead of separate files which personally I don't like it.

I think there's a lot of approaches that we can follow and feel free to share your best approach or other approaches you have.

Finally, if you are reading this line I think the topic was interesting for you.

Thank you

DEV Community: Othmane Nemli

Laravel Context: The Hidden Information That Follows Your Code

What is Laravel Context?

The simplest example

The really useful part: logging

But here's where Context gets interesting

Gere's the interesting part

Context can also be hidden

Context can have a lifecycle

Context is more than key/value storage

When should you use it?

One important rule

At the end, is it another Laravel key/value?

Vite+ — Chapter 5: Should You Use Vite+?

1. First: What Is Vite+ Really?

2. The Problem Vite+ Is Trying to Solve

3. When Vite+ Makes Sense

Growing projects

4. Teams That Want Consistency

5. Monorepos

6. When Vite+ May Not Be Necessary

7. Don't Adopt Tools Just Because They're New

8. What About Existing Vite Projects?

9. Migration Is More Than Changing Commands

Development

Tests

Formatting

Linting

CI

Builds

10. Vite+ Is Still Evolving

11. Beta Doesn't Mean "Don't Use It"

Experiment

Team project

12. What About Performance?

13. Developer Experience Matters Too

14. But Don't Ignore Your Existing Ecosystem

15. A Practical Evaluation Strategy

Step 1 — Pick a representative project

Step 2 — Establish a baseline

Step 3 — Migrate

Step 4 — Test CI

Step 5 — Compare

16. The Most Important Lesson

17. Vite+ Doesn't Make Individual Tools Disappear

19. To wrap things up

Vite+ — Chapter 4: Vite+ at Scale — Monorepos, Tasks, Caching, and CI

1. What Is a Monorepo?

2. The Dependency Problem

3. What Is a Task?

4. Enter vp run

5. Task Dependencies

6. Why Dependency-Aware Execution Matters

7. Caching

8. What Does the Cache Actually Mean?

9. Cache Hits and Cache Misses

Cache hit

Cache miss

10. Why This Matters in CI

11. Vite+ and GitHub Actions

12. Local Development and CI Use the Same Interface

13. A Monorepo Example

14. Parallelism

15. vp run Is More Than npm run

16. Filtering Tasks

17. One Configuration for the Whole Toolchain

18. But Caching Isn't Magic

19. Don't Treat Cache Hits as Guaranteed

20. A Practical CI Pipeline

21. When Does This Actually Matter?

22. The Big Picture

Small application

Large monorepo

23. Ssummary

Monorepos

Tasks

Dependency graphs

Caching

Parallel execution

CI

4. Enter `vp run`

15. `vp run` Is More Than `npm run`

12. And Then There's `vp run`

Meet `whereBinary()`