-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add template.visibleFiles
option
#165
base: main
Are you sure you want to change the base?
feat: add template.visibleFiles
option
#165
Conversation
Run & review this pull request in StackBlitz Codeflow. |
3a11ee5
to
5368ef2
Compare
0e4e9e4
to
4b0695d
Compare
Tested manually with AriPerkkio/tutorial-vite-plugin#15 - the amount of removed duplicate files is a lot! As this changes quite a lot how editor's files are resolved, I think we should wait for @Nemikolh or @SamVerschueren to review this next week. |
<Tabs syncKey="file-visibilty"> | ||
<TabItem label="Initially"> | ||
|
||
```markdown ins=/.{24}├── (first.js)/ ins=/└── (second.js)/ ins=/third.js/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing _files/src
here 😱
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! I have a couple of comments but my biggest point is that I would want us to have visibleFiles
entries match's git's .gitignore
format.
On a TutorialKit project, I expect most of our users to use git to version their tutorial and so I think it's reasonable to expect from them to be more familiar with the .gitignore
format than something else. I think it's similar to globs but a comment in this PR make me think that maybe it doesn't work exactly the same.
@@ -347,6 +366,15 @@ async function getFilesRefList(pathToFolder: string): Promise<FilesRefList> { | |||
return [filesRef, filePaths]; | |||
} | |||
|
|||
function formatTemplateFile(filename: string) { | |||
// compare files without leading "/" so that patterns like ["src/index.js"] match "/src/index.js" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not super familiar with micromatch, but this comment and the logic after make me think that maybe this is not the library that we want?
I think we should have visibleFiles
entries follow a similar format to git
's gitignore
entries. That would lower the learning curve of TutorialKit a lot and not necessitate as much trial and error for users.
In particular if you say:
template:
visibleFiles:
- /foobar
It should not match /test/foobar
but match a /foobar
file in the template.
If you mean to match every file named foobar
then you can only say foobar
or **/foobar
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I picked micromatch
since it's already a transitive dependency from fast-glob
.
.gitignore
doesn't require prefixing all files with /
? Meaning that:
$ touch new-file.ts
$ git status
Untracked files:
(use "git add <file>..." to include in what will be committed)
new-file.ts
$ echo "new-file.ts" >> .gitignore
$ git status
Changes not staged for commit:
modified: .gitignore
What formatTemplateFile
here does, is that it allows you to define visibleFiles: ["src/main.js"]
instead of ["/src/main.js"]
. Do we want to revert this /
handling?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Though I guess metadata's focus
option does require /
prefixes for all files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Nemikolh here's small playground to check how it works:
https://stackblitz.com/~/edit/stackblitz-starters-efozpk?file=index.mjs
node index.mjs
to run.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I modified the example a bit to showcase what I mean: https://stackblitz.com/~/edit/stackblitz-starters-bq7pxo.
So basically when we have:
[
'/foobar/a.js',
'/a.js',
]
If you have a .gitignore
that says:
a.js
then it will ignore both files. But if it says /a.js
, it will only ignore the second one.
With micromatch
only, it doesn't work. We might make it work with a bit more work. Like if the input in the array does not start with /
we can add **/
to it and it might produce the same behaviour.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I see, thanks for the example! Does it work correctly if basename: true
is used?
- const isMatch = micromatch.isMatch(file, [pattern]);
+ const isMatch = micromatch.isMatch(file, [pattern], { basename: true });
{ file: '/foobar/a.js', pattern: 'a.js', isMatch: true }
{ file: '/a.js', pattern: 'a.js', isMatch: true }
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh looks like this is working! This might be good enough?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now using basename: true
.
1a64db3
to
8f59cf9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noticed a really important detail that regardless of the behaviour of the matching should be addressed.
|
||
this._editorStore.setDocuments(files); | ||
const editorFiles = { ...this._visibleTemplateFiles, ...this._lessonFiles }; | ||
this._editorStore.setDocuments(editorFiles); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just noticed that the files from the template are not read-only.
Given that they aren't part of the lesson but are here to provide information on the project, I really feel like they should be read only. Otherwise it feels like we're moving too far away from the original goal of having tutorials be this "safe" environment where learners can focus on the learning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we have options to make any file readonly at the moment. Maybe we need such feature, especially once adding new files via terminal becomes possible?
Currently it's intentional that files are modifiable. This is simply to reduce repetition - you don't have to copy-paste files in every single lesson just to make them visible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we have options to make any file readonly at the moment. Maybe we need such feature, especially once adding new files via terminal becomes possible?
That is correct, until this PR we didn't have a need for them.
I'm not quite sure what we want to do about files being added from a terminal or more generally added in WebContainer by any mean, but I'm tempted to think that we'll want to design a solution that around a specific example.
Currently it's intentional that files are modifiable. This is simply to reduce repetition - you don't have to copy-paste files in every single lesson just to make them visible.
Then IMO it's the wrong abstraction. I never saw visibleFiles
as intended to reduce repetition in _files
. If we want that then we should maybe consider allowing .tk-config.json
in _files
(which I think already works but isn't documented) or have a different approach. This feels a bit hacky and against the original idea that templates are not part of the lesson (as in initial files to modify or the final solution).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Otherwise it feels like we're moving too far away from the original goal of having tutorials be this "safe" environment where learners can focus on the learning.
Yep, it sounds like we need to reconsider these changes. Maybe it's best to have only files from _files
visible, as it currently is. Having files that aren't modifiable in file tree could make tutorials even more confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this option shouldn't even be on template
, it should be just file system based one. 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh that's a good point actually! It's not really a template property but more like what we should show from the fs regardless of where it's coming from.
Hmm I agree maybe this is something we should discuss further, maybe we could start a thread on twitter about it and ping people that have requested the feature? Or maybe we can have the conversation in a GitHub issue.
template.visibleFiles
option that can be used to toggle files from template visible in lessonstemplate.visibleFiles
to reduce repetition AriPerkkio/tutorial-vite-plugin#15Files
of the current lesson #393