Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

☂️ Plan for 2026 Q3 (Jul - Sep)

Geschlossen
  • Stimmt etwas nicht?
#2,405 2 Kommentare 28 Reaktionen 1 zugewiesene Person Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@fengmk2 arbeitet bereits daran.

Seit 11.8.2026.

Bewertung

Dieses Issue wurde noch nicht bewertet.

Beschreibung

This plan shows our community and collaborators our current goals and timelines.

Our main goal for Q3 is to release Vite+ 1.0.

This list is not complete. Search the existing issues first. If you need a feature that is not here, add a comment to this issue. Write a detailed description of the requirement.

You can also find us on Discord.

What 1.0 means

1.0 is a commitment to stability. This is what it covers:

  • Semver applies to the vp CLI and to the Vite+ config schema. Command names, flags, config keys, and the locations of generated files will not change in 1.x.
  • Bundled tools keep their own version numbers. Vite+ 1.0 does not mean that each bundled tool is also 1.0. We will document this policy.
  • We will publish a list of the supported platforms. The list will show the operating system, the architecture, the libc version, and the Node.js version.

Breaking changes come before 1.0

These changes are difficult to make after 1.0. Thus we will make them first:

  • Rename the environment variables that start with VITE_ (#2206)
  • Move the configuration to the XDG paths (#827)
  • Change how vp finds a custom cache directory (#2298)
  • Remove the lint and format wrapper bin, to make IDE support stable (#1557)
    • Correct the bin conflict with oxlint and oxfmt (#1482)
  • Complete the alias strategy (#2023)
  • Change how Vite+ manages package managers (#2375)

The package-manager change has three parts:

  1. Vite+ will replace Corepack with its own shims for npm, pnpm, Yarn, and Bun.
  2. vp env will manage the package manager and Node.js together. The pin, use, install, clean, and current commands will control both.
  3. Ordinary package-manager commands will resolve and run the appropriate Vite+-managed package manager without implicitly modifying package.json.

This change affects you if you use Corepack directly, if your scripts read vp env --json, or if your workflow relies on package-manager commands implicitly adding or updating package-manager metadata in package.json. Most other workflows stay the same.

Tell us now if your project depends on one of these changes.

Correctness and stability

Monorepo behavior:

  • Decide what vp dev does in the root directory of a monorepo (#770)
  • Correct vp create when it runs in a monorepo (#820)
  • Correct vp run --filter, which reports a cycle that does not exist (#1610)
  • Let vp staged find the workspace-root config from a subdirectory (#2177)

Windows and WSL2. In these items, fspy is the file-access tracker that task caching uses:

  • Install vp in LocalAppData (#1592)
  • Correct fspy, which fails on WSL2 (#1643)
  • Correct the fspy tests, which fail when node finds the Vite+ shim (#1599)

Core correctness:

  • Remove the circular binding resolution between vite-plus-core and vite-plus (#2054)
  • Correct mergeConfig, which breaks the build of other packages (#1709)
  • Add support for Vite SSG (#1315)

CI and developer experience:

  • Validate the IDE configuration (#1456)
  • Add a ci subcommand that does a clean install (#1389)
  • Keep the output of the oxlint GitHub reporter in vp check (#925)

Vitest 5

vp test runs Vitest. Vite+ declares Vitest as a dependency and ships it with the CLI. In Q3 we will move that dependency from Vitest 4 to Vitest 5.

Vitest 5 adds a browser trace view, a new benchmarking API, and support for nested projects. It also makes large workspaces faster, because inline projects can now share one Vite server.

  • Vitest writes report artifacts under .vitest/. This applies to the HTML, JSON, JUnit, and blob reporters, and to the attachments directory.
  • Vitest clears mocks before each test.
  • The benchmark API is new.
  • A new sharedViteServer option is on by default.

We will:

  • Update the Vitest dependency and all the @vitest/* packages
  • Update the vite-plus/test* exports for the new Vitest API
  • Update Vite+ for the new Vitest plugin and configuration API
  • Write a migration guide for the users of vp test

We will make this change before 1.0. If we make it after 1.0, the behavior of vp test changes soon after a release that we call stable.

Remote task caching (Experimental Feature)

Local caching in Vite Task is complete. In Q3 we will add:

  • Remote caching (#1519)
  • Cache configuration for vp build and vp pack (#2011)
  • GitHub Actions cache support in setup-vp (#2013)

More migration options

These paths upgrade a project to Vite+, or to a new Vite+ version:

  • Upgrade an existing Vite+ project to a new Vite+ version
  • Migrate a project from vite@7 to Vite+
  • Migrate a project from vitest@3 to Vite+

These paths migrate a project from a different tool:

  • Migrate from Turborepo and Nx
  • Migrate from Jest ref
  • Migrate from tsup and tsdown to vp pack (#2101)
  • Migrate from Biome

We will also improve the quality of the migration:

  • Correct the problems that our tests on real projects found (#2037)
  • Migrate the ESLint configuration of each workspace package in a monorepo (#1168)
  • Migrate only the given directory, and not the workspace root (#2124)
  • Stop vp migrate from hanging when the pinned pnpm stops during the install (#2020)

Distribution

We will distribute vp through more channels:

We will also make installation more reliable:

  • Report an error when the installation does not complete (#2170)
  • Record the version range of a global bin installation (#2247)

Version pinning: When you install vp with a system package manager, your project keeps its own Vite+ version. The global vp finds the project-local version and runs it. A new global installation does not upgrade a project that has a pinned version.

Linux: We will publish a list of the supported libc versions and architectures. We will not make a package for each distribution.

Agent support

We want Vite+ to be the default toolchain for agent-driven JavaScript development. In Q3 we will add:

  • An official Vite+ agent skill. The skill will show the vp command patterns and the workflows.
  • A guide for coding agents that use the vp commands (#1537)

vp doc (on hold)

See https://github.com/voidzero-dev/vite-plus/pull/2476#issuecomment-5322359939

vp install improvements

A warm install is an install that finds all the necessary files in the package store. The global virtual store is a store layout that shares one copy of each package between projects. In Q3 we will:

  • Make warm installs faster with the global virtual store of pnpm
  • Support pnpm v12
  • Support npm v12 (#1823)
  • Improve the security defaults (#1419, #1806, #1826)

Not planned for Q3

We will not do this work in Q3:

  • An MCP server for vp
  • Auto-accessor transpilation. This work depends on Oxc. (#1556)
  • vp deploy. This work waits for the Vite Deploy RFC.
  • The IntelliJ extension pack (#919)
  • A dependency graph visualization for monorepos (#1182)
  • More integration with Nuxt and Astro (#1506)
Vorherrschende Sprache
Rust
Sterne
6.5k
Forks
296
Ø Merge
1 T. 2 Std.
Gemergte PRs (30 T.)
230

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus voidzero-dev/vite-plus

Alle Issues in voidzero-dev/vite-plus

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.