If I create a directory with a name that starts with a dot, will the system not recognize it?

[okathira]

Describe the bug

I create a directory with a name that starts with a dot, will the system (Stackblitz or WebContainer? i dont know) not recognize it. chrome on windows. like this,

await mkdir(`./.directory`, { recursive: true });

Since the mkdir function itself is working, I am reporting this problem as a “bug” rather than a “support” or “feature” problem.

Link to the blitz that caused the error

https://stackblitz.com/edit/stackblitz-starters-nwchkmq2?file=storybookScript.js,main.js

Steps to reproduce

1. Open the link.
2. Check current directory and files at this point.
3. Run npm run main.
4. Ensure that a directory with a name beginning with a dot is created but does not appear in the sidebar FILES.
5. Save (or fork) project.
6. Reload browser.
7. Run ls -a to confirm that the directory has been removed.

Expected behavior

Created directory with a name that starts with a dot is also reflected in the GUI and saved.

Parity with Local

• [x] I have run the project in my local machine and I could not reproduce the issue.

Screenshots

a created directory with a name beginning with a dot (.directory) does not appear in the GUI.

Platform

Browser name  = Chrome
Full version  = 134.0.0.0
Major version = 134
navigator.appName = Netscape
navigator.userAgent = Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36
performance.memory = {
  "totalJSHeapSize": 129836947,
  "usedJSHeapSize": 123973911,
  "jsHeapSizeLimit": 4294705152
}
Hash = 33edf5bb

Additional context

same? https://github.com/stackblitz/webcontainer-core/issues/1439

[okathira]

I have also confirmed this in Chrome on Mac.

Browser name  = Chrome
Full version  = 134.0.0.0
Major version = 134
navigator.appName = Netscape
navigator.userAgent = Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36
performance.memory = {
  "totalJSHeapSize": 155485382,
  "usedJSHeapSize": 121677162,
  "jsHeapSizeLimit": 4294705152
}
Hash = 33edf5bb

[okathira]

@SamVerschueren Could you check out this issue? I am wondering if this issue could help to resolve https://github.com/stackblitz/webcontainer-core/issues/1439.

[SamVerschueren]

The directory gets created, but we don't store/sync hidden directories (and I believe files) to the backend. The reason is that most of these are build/output folders. The directory does exist when you create it, it's just gone after a refresh.

[okathira]

@SamVerschueren Thank you for your quick reply!

So this is the behavior as specified? I did not know this. Then I would think that in some frameworks this behavior would be fatal. Therefore, I would be happy if there is documentation and configuration for this somewhere, do these exist?

Personally, I wish we could use something like a .gitignore file to determine if build/output folders or not.

[SamVerschueren]

Then I would think that in some frameworks this behavior would be fatal.

Why would this behaviour be fatal? The directory exists on the file system, it's just not visible in the UI, it's a hidden directory. If a framework under the hood would write to that directory, it should just work. If that directory contains files that need to be served as part of a webserver, that should just work. It's purely hidden in the UI file tree. Plus the additional fact that it's not saved in our database, but that has no impact on the runtime as the folder is usually recreated again by the framework when the website is build again.

[okathira]

@SamVerschueren For example, consider a library that stores its configuration files in a hidden directory. This library creates a hidden directory as a configuration folder during installation rather than as a build/output folder during the build process. I shared a StackBlitz project after installing the library, but because the hidden directory wasn’t saved, the library couldn’t read its configuration, which resulted in an error. This is one possible scenario.

In fact, running npm create storybook@latest generates a .storybook directory for configuration purposes. I previously submitted an issue to Storybook and used StackBlitz to reproduce a problem. However, because the hidden directory wasn’t visible in the UI and wasn’t saved, it caused confusion and errors.

I hope my English explanation is clear.