Marko: Support discovery of files named according to their directory, instead of just index.marko

[christopherjbaker]

New Feature

Description

I would propose that, in addition to finding the current defaults, that it also look for files named according to the directory: <whatever>/<whatever>.marko, <whatever>/<whatever>.style.scss, and <whatever>/<whatever>.component.js.

Context

Currently, the tag discovery will find components/<whatever>.marko or components/<whatever>/index.marko. I prefer not to have index.<ext> files everywhere, however. With normal requires, I avoid index.js by naming the file according to the directory, such as foo/foo.js and requiring foo/foo (or adding a plugin to my build system to check for that). The problem is exacerbated when I use a multi-file component, as I need index.marko, style.scss, and component.js.

Possible Implementation

I did a test implementation by adding conditionals to populate the fileMap in compiler/taglib-loader/scanTagsDir.js. My familiarity with the code base is not high enough yet to know if this is the best way, however. If you have a different suggestion, by all means!

Open Questions

As this is using the same naming conventions that already exist, just applying them in a different scenario, I can't think of any open questions.

Is this something you're interested in working on?

Yes! Did a test implementation as above. If interested, I can open a PR.

[mlrawlings]

I'm mostly on board with this.

Editors typically show the path when you have files with the same name, but different locations open:

However, I see this collapse when you have many files open (as I often do 😄):

Additionally, because tag imports are implicit in Marko, in most cases you won't have to write require('tag-name/tag-name') anywhere in your application code.

My only hesitation lies in not wanting to have so many ways to accomplish the same thing.

[austinkelleher]

I agree that we should allow for greater flexibility in component discovery, but I also agree with @mlrawlings that supporting many different ways of accomplishing the same thing in the Marko code can get messy as well as result in inconsistent codebases.

Instead of supporting all of these methods natively in Marko and having to document each individual method, thoughts on allowing a custom component resolution method to be registered via JavaScript API? Similar to how we allow for a custom test matcher in marko-cli.

/cc @mlrawlings @patrick-steele-idem Thoughts?

[mlrawlings]

If we were to support such a thing, it would need to be through a config file. If it were registered as part of the application code, editor plugins like autocomplete/hyperclick would not be able to find tags, nor would a compile that happened outside the application context like marko-cli or standalone builds of webpack orlasso.

[fineline]

This would improve a number of scenarios which aren't currently ideal, such as:

• debugging in dev tools, wish to open the JS file for a particular component, hit Cmd-O to open the file finder and type "component.js" - get a result for every component in the project
• try instead to use the folder name to search by, this does kind of work but generally you have to type the whole folder name before getting suggestions of contained files
• after finding the problem in the debugger, go back to your coding environment to open the file for modification - all the same points as above apply
• after fixing the problem, review the commit to git (and for any approvers review the pull/merge request) - there is more mental gymnastics to sort out the various different same-named files and which components they actually relate to

This isn't fancy conference-keynote stuff, but it is the kind of thing that affects the real-world, day-in day-out experience of using a framework. If you're the kind of person that always uses a tree view to navigate to files it's not such a big deal. But doing a quick "ctrl-o (or whatever your shortcut is) -> first few letters of component name" is a much quicker and very common way to navigate to files. It would be great to support it.