feat: fs-serve import graph awareness

[antfu]

Description

resolve #2820, resolve #3373

• Accessing restricted files now emits warning in console.
• New server.fsServe.allow options is introduced to have multiple safe roots
  • This is for marking vite's client code as safe (when it's linked from other directory), also resolves [Feature Request] Internal allowlist of @fs serving files #3373
  • Currently this serves same functionality as root, should we unify them with allow: string | string[]?
• Imports from "safe modules" are marked as "safe"

Additional context

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the Commit Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[Shinigami92]

Tests also seem to not pass 🙁

[antfu]

Force pushed to make commit history cleaner.

Code changes: 95dbcf4
Test: 3b8f5

[Shinigami92]

Failing test on windows

[antfu]

Finally 🙃

[patak-dev]

Great to have proper tests for this feature now ❤️

• Accessing restricted files now emits warning in console.

+1

• New server.fsServe.dirs options is introduced to have multiple safe roots

If I recall correctly from Marvin, this is also the approach that WMR took. But I can't find the option in their docs now.

• This is for marking vite's client code as safe (when it's linked from other directory), also resolves [Feature Request] Internal allowlist of @fs serving files #3373

Does this mean that if you yarn link something, you need to add it to the dirs list? Doesn't these linked imports fall into the Imports from "safe modules" are marked as "safe"? If not, is there a way to make linked files also work?
Maybe by also marking as safe the real paths for symlinks (using realpath for example). If there is a performance penalty maybe this could be behind a fsServe.allowSymlinks options, but hoping that this could be on by default and people could opt-out (we are already using it for handling source maps, looks like it is included as a dependency that works better than node's default).

• Currently this serves same functionality as root, should we unify them with allow: string | string[]?

I would prefer that we deprecate root and only include one option. Your proposal sounds good to me allow: string | string[], and it also leaves the door open to add allow: string | string[] | (path: string, server: ViteServer) => boolean and let people implement their own logic. I think this is good to enable users to customize fsServe without Vite taking extra complexity in core. And we could also add a fsServer.disallow if people want to ban certain directories. As an extra pro, we'll avoid future confusion between root and fsServe.root, but this is not a hard reason.

• Imports from "safe modules" are marked as "safe"

This is awesome

[antfu]

Does this mean that if you yarn link something, you need to add it to the dirs list?

No, they should be automated marked as safe I think. The @vite/client thing is a bit special I guess. Tho I will try to find a way to make it more general so we can have this PR without new options and left it for the future PRs.

Imports from "safe modules" are marked as "safe"

This should work theoretically, however I can't still be 100% sure. It will be great if you can link it to your real project and test out :)

[patak-dev]

Tested this in windows in a Vite App and it works fine when yarn linking vite 👍🏼

[antfu]

After some digging, it's still not easy to generalize handling for @vite/client. So I think maybe it's worthwhile to introduce the multiple allow dir list in this PR.

As a result, I renamed it to fsServe.allow: string[] and soft deprecated the fsServe.root options. Still not sure if it's a good name tho.

[Shinigami92]

Is the default false or undefined?

[antfu]

undefined. false to disable the warning

[Shinigami92]

Then we should change the descriptive text in line 141 to something less confusing

[antfu]

Good point

[meteorlxy]

This PR brings new options, so it would be better to mark as feat instead of fix