[GH-ISSUE #1919] [FR]: Browse by folder

kerem commented

2026-02-26 02:35:01 +03:00

Owner

Originally created by @yboulkaid on GitHub (May 12, 2025).
Original GitHub issue: https://github.com/koel/koel/issues/1919

Originally assigned to: @phanan on GitHub.

Description

Hi!

How easy/hard is it to add a folder view to Koel? I have carried my digital music collection with me for 20 years and my folder structure is much better than my metadata organization 😅

It's surprisingly hard to find a self-hosted media browser that has this :( I would even be fine with it as a Koel Plus feature

Cheers!

Additional information

No response

Originally created by @yboulkaid on GitHub (May 12, 2025). Original GitHub issue: https://github.com/koel/koel/issues/1919 Originally assigned to: @phanan on GitHub. ### Description Hi! How easy/hard is it to add a folder view to Koel? I have carried my digital music collection with me for 20 years and my folder structure is much better than my metadata organization 😅 It's surprisingly hard to find a self-hosted media browser that has this :( I would even be fine with it as a Koel Plus feature Cheers! ### Additional information _No response_

kerem closed this issue

2026-02-26 02:35:01 +03:00

kerem commented

2026-02-26 02:35:02 +03:00

Author

Owner

@phanan commented on GitHub (May 13, 2025):

It's not hard if you set out to design and build the functionality as the core feature of a music player from the start, NOT as an afterthought/addon. Imagine the complexity it'd bring to the current features: What would happen to the song list, artist list, album list, genres? How will editing work? How about liking, sharing, adding to / removing from playlists, etc? On every level – client code, API, database, the changes that need to be made for this (relatively) edge case would be massive.

On the other hand, it's relatively easy to find a music tag editor that can fill the tags based on folder structure and file names.

@phanan commented on GitHub (May 13, 2025): It's not hard if you set out to design and build the functionality as the core feature of a music player from the start, NOT as an afterthought/addon. Imagine the complexity it'd bring to the current features: What would happen to the song list, artist list, album list, genres? How will editing work? How about liking, sharing, adding to / removing from playlists, etc? On every level – client code, API, database, the changes that need to be made for this (relatively) edge case would be massive. On the other hand, it's relatively easy to find a music tag editor that can fill the tags based on folder structure and file names.

kerem commented

2026-02-26 02:35:02 +03:00

Author

Owner

@yboulkaid commented on GitHub (May 13, 2025):

Thanks for the answer!

For the sake of discussion: the way I thought about it was more like an additional view of the existing data. You'd keep everything else that is valid for tag-based collections in place, and add a way to browse files instead of songs.

Each song already has a mapping to the physical file path, so it's possible to extract the folder hierarchy structure, and from there make it browsable.

That said, I understand it's your project and if you don't think it aligns with your philosophy it's all good :) Just saying that overall there's an underserved niche of users with file-based workflows, both for audio and image contents (photographers).

Cheers!

@yboulkaid commented on GitHub (May 13, 2025): Thanks for the answer! For the sake of discussion: the way I thought about it was more like an additional view of the existing data. You'd keep everything else that is valid for tag-based collections in place, and add a way to browse files instead of songs. Each song already has a mapping to the physical file path, so it's possible to extract the folder hierarchy structure, and from there make it browsable. That said, I understand it's your project and if you don't think it aligns with your philosophy it's all good :) Just saying that overall there's an underserved niche of users with file-based workflows, both for audio and image contents (photographers). Cheers!

kerem commented

2026-02-26 02:35:02 +03:00

Author

Owner

@phanan commented on GitHub (May 13, 2025):

@yboulkaid I wish it were as simple as just adding a way to browse files instead of songs, really. For example, basing the functionality on the database-stored file paths isn't the best approach, as it would likely require some non-optimized, non-DB-agnostic SQLs, so a better bet would be to read the filesystem on the fly. Then, UI-wise, how should it look? How will virtual scrolling work? Are we providing a menu tree or…? Things will only get more and more complicated from there.

@phanan commented on GitHub (May 13, 2025): @yboulkaid I wish it were as simple as just adding a way to browse files instead of songs, really. For example, basing the functionality on the database-stored file paths isn't the best approach, as it would likely require some non-optimized, non-DB-agnostic SQLs, so a better bet would be to read the filesystem on the fly. Then, UI-wise, how should it look? How will virtual scrolling work? Are we providing a menu tree or…? Things will only get more and more complicated from there.

kerem commented

2026-02-26 02:35:02 +03:00

Author

Owner

@yboulkaid commented on GitHub (May 13, 2025):

I went through the same questions while building the data model for a folder-based photo gallery, sharing my notes and findings here if it's any help/inspiration :)

It's way more convenient to interact with a database than the filesystem. Since we have to persist records for every entry anyway, you already depend on a "cached" version of the filesystem, and you avoid dealing with the filesystem in your app. The goal becomes to create a data model that allows for fast queries.
Create a folders table. The table has a unique index on path and a parent_id foreign key to itself.
Songs have a folder_id foreign key. This makes finding the songs in a folder performant and database-agnostic
On library scanning, create folder records as you traverse the filesystem
To make the folder view, start with the root folder and show its children. If a folder has any songs in it, show them

Where it can be tricky:

Because of parent_id, folders need to be traversed breadth-first so that parents records are always created before children
Handling folder renames and deletes which basically invalidate your data. Though you already have to deal with this for songs so it's not specific to folders, but it adds complexity anyway.
Breadcrumbs are a bit tricky because you have to recursively go up to the parent folders until the root. But even then it's just a couple database calls

So overall it's definitely some added complexity to take for a small niche of users, which is why I think it's acceptable to have it as a Koel Plus feature

@yboulkaid commented on GitHub (May 13, 2025): I went through the same questions while building the data model for a folder-based photo gallery, sharing my notes and findings here if it's any help/inspiration :) 1. It's way more convenient to interact with a database than the filesystem. Since we have to persist records for every entry anyway, you already depend on a "cached" version of the filesystem, and you avoid dealing with the filesystem in your app. The goal becomes to create a data model that allows for fast queries. 2. Create a `folders` table. The table has a unique index on `path` and a `parent_id` foreign key to itself. 3. Songs have a `folder_id` foreign key. This makes finding the songs in a folder performant and database-agnostic 4. On library scanning, create `folder` records as you traverse the filesystem 5. To make the folder view, start with the root folder and show its children. If a folder has any `songs` in it, show them Where it can be tricky: - Because of `parent_id`, folders need to be traversed breadth-first so that parents records are always created before children - Handling folder renames and deletes which basically invalidate your data. Though you already have to deal with this for songs so it's not specific to folders, but it adds complexity anyway. - Breadcrumbs are a bit tricky because you have to recursively go up to the parent folders until the root. But even then it's just a couple database calls So overall it's definitely some added complexity to take for a small niche of users, which is why I think it's acceptable to have it as a Koel Plus feature

kerem commented

2026-02-26 02:35:02 +03:00

Author

Owner

@phanan commented on GitHub (May 14, 2025):

If we totally disregard other views (TBH I'm not the biggest fan of the idea), then yes, I reckon we could add a new screen called "Browse." I'm still not sure, however, how it'd look. A Finder-style list view may work, but how would we deal with folders with thousands of items—if we wanted to at all?

@phanan commented on GitHub (May 14, 2025): If we totally disregard other views (TBH I'm not the biggest fan of the idea), then yes, I reckon we could add a new screen called "Browse." I'm still not sure, however, how it'd look. A Finder-style list view *may* work, but how would we deal with folders with thousands of items—if we wanted to at all?

kerem commented

2026-02-26 02:35:02 +03:00

Author

Owner

@gelokatil commented on GitHub (May 15, 2025):

It would be wonderful if this possible future folder navigation utility would allow adding the contents of a directory directly to create a playlist; perhaps it would be a simpler intermediate option than allowing indexing the physical directory of the music files as another metadata element.

Another option could be to create a third type of playlist (or a new option of the smart playlist) that accepts a directory or disk path as a parameter. Given my lack of knowledge on the subject, considering the development costs, as @phanan has commented, this seems more reasonable.

@gelokatil commented on GitHub (May 15, 2025): It would be wonderful if this possible future folder navigation utility would allow adding the contents of a directory directly to create a playlist; perhaps it would be a simpler intermediate option than allowing indexing the physical directory of the music files as another metadata element. Another option could be to create a third type of playlist (or a new option of the smart playlist) that accepts a directory or disk path as a parameter. Given my lack of knowledge on the subject, considering the development costs, as @phanan has commented, this seems more reasonable.

kerem commented

2026-02-26 02:35:02 +03:00

Author

Owner

@yboulkaid commented on GitHub (May 15, 2025):

If we totally disregard other views (TBH I'm not the biggest fan of the idea), then yes, I reckon we could add a new screen called "Browse." I'm still not sure, however, how it'd look. A Finder-style list view may work, but how would we deal with folders with thousands of items—if we wanted to at all?

IMO folder browsing is orthogonal to the tag-based browsing, so depending on what you mean by "disregard" it can be an acceptable trade-off. Tag-based features would be removed (they don't make sense in a folder view), but song-based ones are enabled.

After playing around yesterday with Swing Music (similar to Koel, and implements a folder view), I brainstormed some of the interactions that would need to be supported, and added some notes:

Play a folder: basically would treat the folder as an ad-hoc playlist, same as what @gelokatil is suggesting. This is the most common use case
From a file, implement "go to artist" and "go to album". It should be straightforward as we already have the associated Song records
Liking a song would be the same flow, it's still a Song record

The challenges:

folders with large number of files, as you said. I think backend-wise it's okay (as long as N+1 queries are avoided, and maybe even then it's not really an issue, since the database is on the same host). The UI could be a challenge if the JS rendering is inefficient
album art: each file can potentially have its own album art, how do we display it?
Sharing: I am not sure if it makes sense, maybe disable it for folders?
Playing all songs in a nested folder: you'd need to recursively traverse folders and add the songs to the playing queue, maybe not needed?

@yboulkaid commented on GitHub (May 15, 2025): > If we totally disregard other views (TBH I'm not the biggest fan of the idea), then yes, I reckon we could add a new screen called "Browse." I'm still not sure, however, how it'd look. A Finder-style list view may work, but how would we deal with folders with thousands of items—if we wanted to at all? IMO folder browsing is orthogonal to the tag-based browsing, so depending on what you mean by "disregard" it can be an acceptable trade-off. Tag-based features would be removed (they don't make sense in a folder view), but song-based ones are enabled. After playing around yesterday with [Swing Music](https://github.com/swingmx/swingmusic) (similar to Koel, and implements a folder view), I brainstormed some of the interactions that would need to be supported, and added some notes: - Play a folder: basically would treat the folder as an ad-hoc playlist, same as what @gelokatil is suggesting. This is the most common use case - From a file, implement "go to artist" and "go to album". It should be straightforward as we already have the associated `Song` records - Liking a song would be the same flow, it's still a `Song` record The challenges: - folders with large number of files, as you said. I think backend-wise it's okay (as long as N+1 queries are avoided, and maybe even then it's not really an issue, since the database is on the same host). The UI could be a challenge if the JS rendering is inefficient - album art: each file can potentially have its own album art, how do we display it? - Sharing: I am not sure if it makes sense, maybe disable it for folders? - Playing all songs in a nested folder: you'd need to recursively traverse folders and add the songs to the playing queue, maybe not needed?

kerem commented

2026-02-26 02:35:02 +03:00

Author

Owner

@phanan commented on GitHub (May 15, 2025):

Sounds like some nice challenges to take :) I guess some of the problems
can only be solved once you encounter them. The biggest issue is still… time.

On Thu, May 15, 2025 at 12:49 Youssef Boulkaid @.***>
wrote:

yboulkaid left a comment (koel/koel#1919)
https://github.com/koel/koel/issues/1919#issuecomment-2883386520

If we totally disregard other views (TBH I'm not the biggest fan of the
idea), then yes, I reckon we could add a new screen called "Browse." I'm
still not sure, however, how it'd look. A Finder-style list view may work,
but how would we deal with folders with thousands of items—if we wanted to
at all?

IMO folder browsing is orthogonal to the tag-based browsing, so depending
on what you mean by "disregard" it can be an acceptable trade-off.
Tag-based features would be removed (they don't make sense in a folder
view), but song-based ones are enabled.

After playing around yesterday with Swing Music
https://github.com/swingmx/swingmusic (similar to Koel, and implements
a folder view), I brainstormed some of the interactions that would need to
be supported, and added some notes:

Play a folder: basically would treat the folder as an ad-hoc
playlist, same as what @gelokatil https://github.com/gelokatil is
suggesting. This is the most common use case

From a file, implement "go to artist" and "go to album". It should
be straightforward as we already have the associated Song records

Liking a song would be the same flow, it's still a Song record

The challenges:

folders with large number of files, as you said. I think
backend-wise it's okay (as long as N+1 queries are avoided, and maybe even
then it's not really an issue, since the database is on the same host). The
UI could be a challenge if the JS rendering is inefficient

album art: each file can potentially have its own album art, how do
we display it?

Sharing: I am not sure if it makes sense, maybe disable it for
folders?

Playing all songs in a nested folder: you'd need to recursively
traverse folders and add the songs to the playing queue, maybe not needed?

—
Reply to this email directly, view it on GitHub
https://github.com/koel/koel/issues/1919#issuecomment-2883386520, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AB5O3USG6MMSXU67NLADA5326RWNFAVCNFSM6AAAAAB47DUJHWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQOBTGM4DMNJSGA
.
You are receiving this because you were mentioned.Message ID:
@.***>

@phanan commented on GitHub (May 15, 2025): Sounds like some nice challenges to take :) I guess some of the problems can only be solved once you encounter them. The biggest issue is still… time. On Thu, May 15, 2025 at 12:49 Youssef Boulkaid ***@***.***> wrote: > *yboulkaid* left a comment (koel/koel#1919) > <https://github.com/koel/koel/issues/1919#issuecomment-2883386520> > > If we totally disregard other views (TBH I'm not the biggest fan of the > idea), then yes, I reckon we could add a new screen called "Browse." I'm > still not sure, however, how it'd look. A Finder-style list view may work, > but how would we deal with folders with thousands of items—if we wanted to > at all? > > IMO folder browsing is orthogonal to the tag-based browsing, so depending > on what you mean by "disregard" it can be an acceptable trade-off. > Tag-based features would be removed (they don't make sense in a folder > view), but song-based ones are enabled. > > After playing around yesterday with Swing Music > <https://github.com/swingmx/swingmusic> (similar to Koel, and implements > a folder view), I brainstormed some of the interactions that would need to > be supported, and added some notes: > > - Play a folder: basically would treat the folder as an ad-hoc > playlist, same as what @gelokatil <https://github.com/gelokatil> is > suggesting. This is the most common use case > - From a file, implement "go to artist" and "go to album". It should > be straightforward as we already have the associated Song records > - Liking a song would be the same flow, it's still a Song record > > The challenges: > > - folders with large number of files, as you said. I think > backend-wise it's okay (as long as N+1 queries are avoided, and maybe even > then it's not really an issue, since the database is on the same host). The > UI could be a challenge if the JS rendering is inefficient > - album art: each file can potentially have its own album art, how do > we display it? > - Sharing: I am not sure if it makes sense, maybe disable it for > folders? > - Playing all songs in a nested folder: you'd need to recursively > traverse folders and add the songs to the playing queue, maybe not needed? > > — > Reply to this email directly, view it on GitHub > <https://github.com/koel/koel/issues/1919#issuecomment-2883386520>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AB5O3USG6MMSXU67NLADA5326RWNFAVCNFSM6AAAAAB47DUJHWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQOBTGM4DMNJSGA> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

kerem commented

2026-02-26 02:35:02 +03:00

Author

Owner

@yboulkaid commented on GitHub (May 15, 2025):

As someone who's also starved for time, hear hear :)

I'll keep an eye on this thread, I'm available if you want to bounce off ideas!

@yboulkaid commented on GitHub (May 15, 2025): As someone who's also starved for time, hear hear :) I'll keep an eye on this thread, I'm available if you want to bounce off ideas!

kerem commented

2026-02-26 02:35:02 +03:00

Author

Owner

@phanan commented on GitHub (May 28, 2025):

@yboulkaid et al. FYI the feature has been added to v7.5.x (Plus edition).

@phanan commented on GitHub (May 28, 2025): @yboulkaid et al. FYI the feature has been added to [v7.5.x](https://github.com/koel/koel/releases/tag/v7.5.0) (Plus edition).

kerem commented

2026-02-26 02:35:02 +03:00

Author

Owner

@gelokatil commented on GitHub (May 28, 2025):

@yboulkaid et al. FYI the feature has been added to v7.5.x (Plus edition).

Perfect! I'll try out the new feature and send you feedback, @phanan

@gelokatil commented on GitHub (May 28, 2025): > [@yboulkaid](https://github.com/yboulkaid) et al. FYI the feature has been added to [v7.5.x](https://github.com/koel/koel/releases/tag/v7.5.0) (Plus edition). Perfect! I'll try out the new feature and send you feedback, @phanan

kerem commented

2026-02-26 02:35:02 +03:00

Author

Owner

@gelokatil commented on GitHub (Jun 22, 2025):

Hi @phanan
I've been testing the new Media Browser feature for a few weeks now, and I honestly can't find any flaws; it works like a charm :) . I have a few drawbacks, or rather, a couple of possible "improvements."

It would be very useful to be able to add a directory or multiple directories to a playlist if it were a tree. Right now, you can only add individual songs, which is fine.

On the other hand, in the Media Browser option, the left side of the window is empty. It might be interesting to fill that space with the song editing window embedded in the window itself, or find another way to edit song attributes directly in the Media Browser, taking advantage of the free space.
Thanks for everything.

@gelokatil commented on GitHub (Jun 22, 2025): Hi @phanan I've been testing the new Media Browser feature for a few weeks now, and I honestly can't find any flaws; it works like a charm :) . I have a few drawbacks, or rather, a couple of possible "improvements." It would be very useful to be able to add a directory or multiple directories to a playlist if it were a tree. Right now, you can only add individual songs, which is fine. On the other hand, in the Media Browser option, the left side of the window is empty. It might be interesting to fill that space with the song editing window embedded in the window itself, or find another way to edit song attributes directly in the Media Browser, taking advantage of the free space. Thanks for everything.

kerem commented

2026-02-26 02:35:02 +03:00

Author

Owner

@phanan commented on GitHub (Jun 22, 2025):

Thanks for the feedback! What do you mean the left side is empty?

On Sun, Jun 22, 2025 at 07:45 Gelo @.***> wrote:

gelokatil left a comment (koel/koel#1919)
https://github.com/koel/koel/issues/1919#issuecomment-2993953574

Hi @phanan https://github.com/phanan
I've been testing the new Media Browser feature for a few weeks now, and I
honestly can't find any flaws; it works like a charm :) . I have a few
drawbacks, or rather, a couple of possible "improvements."

It would be very useful to be able to add a directory or multiple
directories to a playlist if it were a tree. Right now, you can only add
individual songs, which is fine.

On the other hand, in the Media Browser option, the left side of the
window is empty. It might be interesting to fill that space with the song
editing window embedded in the window itself, or find another way to edit
song attributes directly in the Media Browser, taking advantage of the free
space.
Thanks for everything.

—
Reply to this email directly, view it on GitHub
https://github.com/koel/koel/issues/1919#issuecomment-2993953574, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AB5O3URBA7T3QKX2DQQVIND3EY7I5AVCNFSM6AAAAAB47DUJHWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOJTHE2TGNJXGQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

@phanan commented on GitHub (Jun 22, 2025): Thanks for the feedback! What do you mean the left side is empty? On Sun, Jun 22, 2025 at 07:45 Gelo ***@***.***> wrote: > *gelokatil* left a comment (koel/koel#1919) > <https://github.com/koel/koel/issues/1919#issuecomment-2993953574> > > Hi @phanan <https://github.com/phanan> > I've been testing the new Media Browser feature for a few weeks now, and I > honestly can't find any flaws; it works like a charm :) . I have a few > drawbacks, or rather, a couple of possible "improvements." > > It would be very useful to be able to add a directory or multiple > directories to a playlist if it were a tree. Right now, you can only add > individual songs, which is fine. > > On the other hand, in the Media Browser option, the left side of the > window is empty. It might be interesting to fill that space with the song > editing window embedded in the window itself, or find another way to edit > song attributes directly in the Media Browser, taking advantage of the free > space. > Thanks for everything. > > — > Reply to this email directly, view it on GitHub > <https://github.com/koel/koel/issues/1919#issuecomment-2993953574>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AB5O3URBA7T3QKX2DQQVIND3EY7I5AVCNFSM6AAAAAB47DUJHWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOJTHE2TGNJXGQ> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

kerem commented

2026-02-26 02:35:02 +03:00

Author

Owner

@gelokatil commented on GitHub (Jun 22, 2025):

This, (sorry i mean right side)

@gelokatil commented on GitHub (Jun 22, 2025): This, (sorry i mean right side) ![Image](https://github.com/user-attachments/assets/07b0b06e-63a4-420b-b6d0-8ecd4a38a043)

kerem commented

2026-02-26 02:35:02 +03:00

Author

Owner

@phanan commented on GitHub (Jun 22, 2025):

Isn’t that because you’re collapsing both the left and right sidebars? On a
standard laptop screen, it should look fine (I tested with short and long
file names).

On Sun, Jun 22, 2025 at 09:16 Gelo @.***> wrote:

gelokatil left a comment (koel/koel#1919)
https://github.com/koel/koel/issues/1919#issuecomment-2993995087

This,

Captura.desde.2025-06-22.09-13-59.png (view on web)
https://github.com/user-attachments/assets/07b0b06e-63a4-420b-b6d0-8ecd4a38a043

—
Reply to this email directly, view it on GitHub
https://github.com/koel/koel/issues/1919#issuecomment-2993995087, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AB5O3UT3NVBUXFAJ5AY6PZD3EZJ5DAVCNFSM6AAAAAB47DUJHWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOJTHE4TKMBYG4
.
You are receiving this because you were mentioned.Message ID:
@.***>

@phanan commented on GitHub (Jun 22, 2025): Isn’t that because you’re collapsing both the left and right sidebars? On a standard laptop screen, it should look fine (I tested with short and long file names). On Sun, Jun 22, 2025 at 09:16 Gelo ***@***.***> wrote: > *gelokatil* left a comment (koel/koel#1919) > <https://github.com/koel/koel/issues/1919#issuecomment-2993995087> > > This, > > Captura.desde.2025-06-22.09-13-59.png (view on web) > <https://github.com/user-attachments/assets/07b0b06e-63a4-420b-b6d0-8ecd4a38a043> > > — > Reply to this email directly, view it on GitHub > <https://github.com/koel/koel/issues/1919#issuecomment-2993995087>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AB5O3UT3NVBUXFAJ5AY6PZD3EZJ5DAVCNFSM6AAAAAB47DUJHWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOJTHE4TKMBYG4> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

kerem commented

2026-02-26 02:35:02 +03:00

Author

Owner

@gelokatil commented on GitHub (Jun 22, 2025):

Maybe it's because I use a 24-inch desktop monitor but even showing the right panel, (which is not useful in the context of the media browser) there is a lot of free space in the middle.

On a 14-17 inch laptop monitor, I understand it would look much better.

@gelokatil commented on GitHub (Jun 22, 2025): Maybe it's because I use a 24-inch desktop monitor but even showing the right panel, (which is not useful in the context of the media browser) there is a lot of free space in the middle. On a 14-17 inch laptop monitor, I understand it would look much better. ![Image](https://github.com/user-attachments/assets/9fc6a82e-cfab-4f14-9a56-e348c53fd358)

kerem referenced this issue

2026-02-26 03:31:24 +03:00

[PR #1037] [CLOSED] Bump nunomaduro/larastan from 0.3.17 to 0.3.18 #1540

Rows
Columns

[GH-ISSUE #1919] [FR]: Browse by folder #1037

Description

Additional information