feat: add files via file tree

[AriPerkkio]

• Closes Allow the user to add files #263
• Related to Allow the user to add files #204
• Not related to Update _files content with scrips command #208. That one requires WebContainer changes so that we can listen for fs changes.
• While working on the FileTree I noticed plenty of issues with it and created Replace FileTree with accessible third party treeview component #326 as follow-up.

BREAKING CHANGES

• Projects that are using @tutorialkit/react package directly, without TutorialKit need to update <FileTree> component's props.files type

Description

Adds new metadata option that can be used to enable file and folder creation in the file tree. By default this feature is disabled.

---
type: lesson
editor:
  fileTree:
    allowEdits: true
---

tk-filetree-example.webm

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[AriPerkkio]

Early draft PR, mostly so that 81eac67 can be used if #208 is started before this is finalized.

[AriPerkkio]

Added the REMOVE and RENAME here even though they are not yet implemented. This kind of API allows us to extend the functionality later without causing breaking changes.

[Nemikolh]

Did a first pass, good work on this!! 💪

[Nemikolh]

I think we want something more fine grained where you specify in which scope you want to allow files and folder to be added.

[AriPerkkio]

Sounds good! Though this is something that could be implemented after this first PR without breaking the API too, so that true would mean "allow everything".

But I can also take a look at this once I've addressed other review findings. 👍

[AriPerkkio]

@Nemikolh ready for review round 2! 🔔

Added support for identifying files and folders from each other - we no longer require files to have extensions.

However there's still an edge case that causes issues. As we are using filepath as map key here, there's no way for us to have file and folder with same name in the tree.

tutorialkit/packages/runtime/src/store/editor.ts

Line 16 in 38df1f3

export type EditorDocuments = Record<string, EditorDocument>;

So for example this will fail:

test('empty directories are removed when new content is added', () => {
  const store = new EditorStore();
  store.setDocuments({
    example: 'should not be confused as directory',
  });

  store.addFileOrFolder({ path: 'example', type: 'FOLDER' });
  store.addFileOrFolder({ path: 'example/another', type: 'FOLDER' });

  expect(store.files.get().map(toFilename)).toMatchInlineSnapshot(`
    [
      "example/another",
      "example",
    ]
  `);
});

Is this really an issue that users could run into? Maybe not.

[Nemikolh]

@AriPerkkio I'm not up to date with every file systems that exists out there, but AFAIK, in most of them you cannot have a file and a folder named the same. If you think about it, that make sense with the Linux open function and its equivalent in node.

In our case, what matter is what the WebContainer fs does and it does not allow multiple files given a single path. So this is completely fine 👍

[AriPerkkio]

Oh that's right! It does make sense, when you think from the file system's perspective! I guess I was looking at this too much from FileTree's visual representation and didn't realize it's not possible on fs. 💯

[Nemikolh]

Second pass done! I hope I didn't miss anything. I'll probably do another pass tomorrow 🙏

[Nemikolh]

Oh this is a cool way to only require what we use, I wonder if we should use Pick for i18n in other places. I suppose this can be done later. Curious to hear your thoughts on this.

[AriPerkkio]

Yep we should! I saw that there's quite much duplication in couple of places. When we can derive props from their orignal source, we should always do it.

[Nemikolh]

Incredible job on this @AriPerkkio! 🥳 🥳

I'm starting to think we could merge this PR first, and then change the API in a follow-up PR to be:

type GlobPattern = string;

interface P {
  allowEdits?: boolean | GlobPattern | GlobPattern[]
}

That way it wouldn't be a breaking change, we would still support the boolean version with the default value being false.

I got a feeling that some will still want to use true anyway.

What I think we should do in the follow-up PR is to clarify in the docs that only allowing certain patterns (or even a single path) should be preferred.

I would even reference the talk from Rich Harris: FullStack Documentation as a suggestion to why this should be preferred.

[AriPerkkio]

I agree on all points! I'll continue on that next.