Add extension: RubyFS

[kx1bx1]

No, you're not insane, RubyFS was previously named LiFS/Lithium FS, but was rebranded.

New Extension: RubyFS (rubyFS)

This PR introduces RubyFS, an unsandboxed extension that provides a robust, in-memory filesystem environment for TurboWarp projects.

RubyFS is an advancement of the original rxFS concept, designed to give creators more control and security within their virtual file structures.

Fun Fact: RubyFS was created because I didn't like the way that the "list all files under {STR}" block's output went -- I wanted it to be a JSON array.

Key features

The following features distinguish RubyFS from the existing 0832/rxFS2 extension, justifying its inclusion as a separate extension rather than a modification:

• Permissions System: Implements granular user-defined read/write/execute permissions on files and directories. This is a critical feature for building complex, multi-user, or secure virtual environments within a project.
• Size Limits: Allows projects to set explicit maximum size limits for the entire filesystem or individual directories, preventing resource overuse.
• Timestamp Blocks: Adds blocks for checking creation, modification, and access dates/times for files, enhancing auditing and logic control.
• Advanced Path Utilities: Includes blocks for copying files/directories and retrieving the base filename or directory name from a path.

Technical compliance

• The extension adheres to the required open-source license (MIT) and is GPLv3-compatible.
• Scratch.translate used to exist prior to this PR's creation, but is no longer included here because it caused a required check to fail.

Note on this code's origin

Almost the entirety this extension were developed with the assistance of an AI programming tool. I have thoroughly reviewed the code, performed extensive testing, and verified that it meets the required safety and functionality standards before submitting this PR. I used to have a tester program, but I suck at resource management and I reset my PC without backing it up.

LLMs used:

• Primarily Gemini 2.5 Pro
• Gemini 3.0 Pro for some quick bug-tests
• GPT-5.0 for release status
• GPT-5.1 for release status

[kx1bx1]

Wow, thanks to the three failed checks that made me look like a terrible GitHub user... Working on that now.

[kx1bx1]

"thoroughly reviewed the code" I say, as three of my checks fail immediately...

[kx1bx1]

Issues fixed!

[PPPDUD]

Please remove all LLM-generated code from this extension.

[kx1bx1]

Your proposal incorrectly claims that "all strings...include German, Spanish, French, etc., translations within the file". If you review the source code, however, you will notice a complete lack of such functionality. You also added an apparently-hallucinated description field in the getInfo() function that appears to do nothing.

Note: This is a modified except from one of my comments over at #2260.

My apologies, one of the checks (I'm pretty sure) failed for one reason, which was because Scratch.translate was not allowed, so I removed it. Removing Scratch.translate alone removed about 1,000 prettified lines of code. I think my LLM thought "Because there's a description line in the comments, there should be one in getInfo()", which I would've thought too (but I don't know anything). I'd say that's hallucinated.

TL;DR, I'll remove the description part of getInfo(), but I'm still questioning Scratch.translate causing some of the checks to fail... I'll edit my PR removing the info about the translations.

Half of me expected to be sworn into Hell for writing an extension with an LLM, but maybe TurboWarp extension developers are nicer than I perceived.

[PPPDUD]

Your proposal incorrectly claims that "all strings...include German, Spanish, French, etc., translations within the file". If you review the source code, however, you will notice a complete lack of such functionality. You also added an apparently-hallucinated description field in the getInfo() function that appears to do nothing.
Note: This is a modified except from one of my comments over at #2260.

My apologies, one of the checks (I'm pretty sure) failed for one reason, which was because Scratch.translate was not allowed, so I removed it. Removing Scratch.translate alone removed about 1,000 prettified lines of code. I think my LLM thought "Because there's a description line in the comments, there should be one in getInfo()", which I would've thought too (but I don't know anything). I'd say that's hallucinated.

TL;DR, I'll remove the description part of getInfo(), but I'm still questioning Scratch.translate causing some of the checks to fail... I'll edit my PR removing the info about the translations.

Half of me expected to be sworn into Hell for writing an extension with an LLM, but maybe TurboWarp extension developers are nicer than I perceived.

That perception was probably my fault, sorry.

[kx1bx1]

Please remove all LLM-generated code from this extension.

Just saw this lol... If you actually mean this, I can kiss goodbye to LiFS in the TurboWarp Extension Gallery, because as I said, this extension is almost completely LLM-generated. Although, I can't say I didn't expect this.

[PPPDUD]

Please remove all LLM-generated code from this extension.

Just saw this lol... If you actually mean this, I can kiss goodbye to LiFS in the TurboWarp Extension Gallery, because as I said, this extension is almost completely LLM-generated. Although, I can't say I didn't expect this.

I do, but I was a bit harsh. @Brackets-Coder is pretty kind, maybe they can overrule me here?

[Brackets-Coder]

While I'm not opposed to the constructive and supportive use of AI in a developer's workflow, I don't think Turbowarp as a whole accepts extensions generated entirely with AI, mostly because large projects generate with AI deteriorate in quality and functionality. If this extension still proves functional and has no glaring issues, then I'm not opposed to merging it (unless there's a serious licensing problem I'm not aware of), but then again we don't like extensions generated entirely with AI.

[kx1bx1]

While I'm not opposed to the constructive and supportive use of AI in a developer's workflow, I don't think Turbowarp as a whole accepts extensions generated entirely with AI, mostly because large projects generate with AI deteriorate in quality and functionality. If this extension still proves functional and has no glaring issues, then I'm not opposed to merging it (unless there's a serious licensing problem I'm not aware of), but then again we don't like extensions generated entirely with AI.

I am yet to develop an entire project with LiFS (however I might with an expansion of one my of in-development Scratch games), but from my testing, every block works, and stress testing completed successfully. You can even turn on console logging if some blocks don't work. I don't really find an issue with LLMs creating extensions, but your claim on projects developed by AI deteriorating is valid, and has happened to me before -- but not with LiFS. Sorry if I sound stupid right now (I probably am).

[PPPDUD]

Your thumbnail's pretty awesome!

Sorry.

[kx1bx1]

Your thumbnail's pretty awesome!

Thank you! I made it in Canva.

[PPPDUD]

@ohgodwhy2k I'm a bit busy at the moment; would someone else be willing to review in my place?

[kx1bx1]

Might mark this as a draft because I'm constantly updating RubyFS, not sure though.

[Brackets-Coder]

Might mark this as a draft because I'm constantly updating RubyFS, not sure though.

If your extension is not yet finalized that would be the best thing to do for organization and clarity

[kx1bx1]

I love how this got marked as draft and as soon as it did, no more updates happened until forever. I'll probably keep it as a draft until RubyFS v2.0.0.

[Brackets-Coder]

I love how this got marked as draft and as soon as it did, no more updates happened until forever. I'll probably keep it as a draft until RubyFS v2.0.0.

If you're concerned about your lack of progress and the extension is functional now, it might be better to have it merged and push major updates later

[Brackets-Coder]

If the extension requires significant work to be production-ready I would keep it as a draft.

[PPPDUD]

I love how this got marked as draft and as soon as it did, no more updates happened until forever. I'll probably keep it as a draft until RubyFS v2.0.0.

If you're concerned about your lack of progress and the extension is functional now, it might be better to have it merged and push major updates later

@ohgodwhy2k To add to this comment, I think that it's worth noting that you can always distribute your extension unofficially in the meantime.

[kx1bx1]

If the extension requires significant work to be production-ready I would keep it as a draft.

I don't think this extension needs work to be production ready, I just want to wait to add more features (however RubyFs's block set is rather humongous).

[Brackets-Coder]

If the extension requires significant work to be production-ready I would keep it as a draft.

I don't think this extension needs work to be production ready, I just want to wait to add more features (however RubyFs's block set is rather humongous).

If this is ready now we can start the review process and you can add more features later.

[kx1bx1]

If the extension requires significant work to be production-ready I would keep it as a draft.

I don't think this extension needs work to be production ready, I just want to wait to add more features (however RubyFs's block set is rather humongous).

If this is ready now we can start the review process and you can add more features later.

Yeah, it is. Sorry if I'm sounding tight-fisted or hard to work with. I'm not very educated on pull requests so I'm bound to get something wrong. But yes, reviewing can start now if you want. (thumbs-up emoji)

[PPPDUD]

If the extension requires significant work to be production-ready I would keep it as a draft.

I don't think this extension needs work to be production ready, I just want to wait to add more features (however RubyFs's block set is rather humongous).

If this is ready now we can start the review process and you can add more features later.

Yeah, it is. Sorry if I'm sounding tight-fisted or hard to work with. I'm not very educated on pull requests so I'm bound to get something wrong. But yes, reviewing can start now if you want. (thumbs-up emoji)

We all have to start from somewhere; I made several failed PRs (#1492, #1495 and #1995 were some of the worst) before I could get anything merged.

[kx1bx1]

If the extension requires significant work to be production-ready I would keep it as a draft.

I don't think this extension needs work to be production ready, I just want to wait to add more features (however RubyFs's block set is rather humongous).

If this is ready now we can start the review process and you can add more features later.

Yeah, it is. Sorry if I'm sounding tight-fisted or hard to work with. I'm not very educated on pull requests so I'm bound to get something wrong. But yes, reviewing can start now if you want. (thumbs-up emoji)

We all have to start from somewhere; I made several failed PRs (#1492, #1495 and #1995 were some of the worst) before I could get anything merged.

Read the first PR and a Fetch+ extension with a built-in CORS proxy would be pretty nice.

[kx1bx1]

Hi @Brackets-Coder @PPPDUD — quick ping: all checks pass and I’ve audited/fixed the earlier issues. I manually tested all core blocks (create/open/list/copy/delete, import/export) and ran the built-in integrity test (PASS). I used LLMs to assist testing/debugging but I personally reviewed the code, and everything seems to work. Could you re-check and approve if everything looks OK, or let me know any remaining changes? Thanks!