An advanced version of rxFS, named LiFS (Lithium FileSystem)

[ohgodwhy2k]

New Extension: Lithium FS/FileSystem (lithiumFS)

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

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

Fun Fact: Lithium FS 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 Lithium FS 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

[ohgodwhy2k]

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

[ohgodwhy2k]

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

[ohgodwhy2k]

Issues fixed!

[PPPDUD]

Please remove all LLM-generated code from this extension.

[ohgodwhy2k]

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.

[ohgodwhy2k]

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.

[ohgodwhy2k]

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.

[ohgodwhy2k]

Your thumbnail's pretty awesome!

Thank you! I made it in Canva.

[ohgodwhy2k]

Issue: In my test of npm start after I pulled the upstream changes from TurboWarp/extensions, the server stopped working and replied:

TypeError: Cannot read properties of undefined (reading 'getMetadata')
    at file:///workspaces/extensions/development/builder.js:404:40
    at Array.map (<anonymous>)
    at HomepageFile.read (file:///workspaces/extensions/development/builder.js:401:26)
    at file:///workspaces/extensions/development/server.js:63:30
    at Layer.handleRequest (/workspaces/extensions/node_modules/router/lib/layer.js:152:17)
    at trimPrefix (/workspaces/extensions/node_modules/router/index.js:342:13)
    at /workspaces/extensions/node_modules/router/index.js:297:9
    at processParams (/workspaces/extensions/node_modules/router/index.js:582:12)
    at next (/workspaces/extensions/node_modules/router/index.js:291:5)
    at file:///workspaces/extensions/development/server.js:42:3

I don't really know if this is a me issue or a prod issue, probably a me issue, but I'll post it here anyways.

[GarboMuffin]

these have to be in sync

[ohgodwhy2k]

these have to be in sync

Noticed this as soon as you posted this -- definitely a me issue lol. It's fixed now!

[ohgodwhy2k]

You appear to use the word unsandboxed as some sort of bragging point; how does using it support the idea that your extension is worthy of being merged?

Didn't realize this comment existed until now, but:

I only added the word "unsandboxed" for members who were going to test this in the TurboWarp environment. The fact that LiFS runs sandboxed is not meant to be a selling point, main feature, or a bragging point, nor is it a reason to merge (since it won't matter anyways because all extensions in the Extension Gallery run unsandboxed anyways).