Skip to content

About

[READ ONLY] Subtree split of the filesystem component (see hypervel/components)

Resources

Stars

0 stars

Watchers

1 watching

Forks

Latest commit

 

History

195 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 

Repository files navigation

Filesystem for Hypervel

Ask DeepWiki

Documentation: https://hypervel.org/docs/filesystem

Differences From Laravel

Hypervel omits Laravel's legacy Storage::cloud() / filesystem.cloud default-cloud shortcut. Use named disks via Storage::disk(...) instead.

Hypervel's Filesystem::hash() method uses xxh128 by default instead of md5. Pass md5 explicitly when Laravel-compatible digests are required.

Custom implementations of Hypervel\Contracts\Filesystem\Filesystem must provide fileExists() and directoryExists() as well as exists(), which accepts either kind of path.

The configured disk name ondemand is reserved. Disks explicitly set under that name, including fakes, intercept anonymous build() calls; configured disks with that name are rejected on resolution.

Hypervel pools S3 and Google Cloud Storage SDK clients rather than complete disk adapters. Disks with equivalent client construction config share the expensive client pool while retaining their own bucket, root, visibility, and callback behavior. FTP and SFTP disks are pooled whole, because each adapter holds one connection that concurrent requests must not share. Pooled disks expose raw internals only through borrow-scoped withClient(), withDriver(), and withAdapter() callbacks.

On read-through disks, raw listContents() results from pooled, S3 and Google Cloud Storage sides are fully loaded instead of streamed.

Filesystem construction differs from Laravel in how it carries logical disk identity. callCustomCreator() accepts the logical disk name as an optional second parameter, so existing one-argument calls remain valid while overrides must adopt the parameter. The public build() method uses a logical-name-aware construction path rather than the protected resolve() method because anonymous builds must pass a null name to creators; resolve() remains the configured-disk seam. createScopedDriver() resolves its prepared descriptor directly rather than through build(), so override createScopedDriver() for scoped construction customization. Customize on-demand construction through Storage::extend() or the public driver creator methods. Creator callbacks may accept the nullable name as a third argument after the application and configuration, while existing two-argument callbacks remain valid. Hypervel carries the name through scoped reconstruction and whole-driver pool fingerprints. A matching explicit fingerprint declares that every construction detail is equivalent, including serving-route ownership.

formatS3Config() leaves named credential providers as configuration data so they can define pool identity. Override createS3Client() to customize provider resolution; see the porting guide.

Hypervel registers signed file-serving routes for any configured disk whose serve option is exactly true, while Laravel limits these routes to local disks and accepts truthy values. Every served disk must use a unique URL or application boot will fail. Custom drivers that opt in must provide the filesystem response methods used by these routes.

Hypervel also provides ScopedFilesystemProxy and ScopedCloudFilesystemProxy for prefixes resolved independently on every operation. The underlying disk may be fixed or resolved once per operation when its configuration varies with the current context. These decorators fail closed on empty prefixes and reject unmapped calls so request- or tenant-scoped boundaries cannot be bypassed.

Ported from: https://github.com/laravel/framework (illuminate/filesystem)

About

[READ ONLY] Subtree split of the filesystem component (see hypervel/components)

Resources

Stars

0 stars

Watchers

1 watching

Forks

Releases

Sponsor this project

Packages

Used by

Contributors

Languages