Feature Request/Exploration: de-structure flag

[AHBruns]

I've very much enjoyed using destiny, and I have found it to be very useful even with it's limited API (in many ways, I actually enjoy the lack of customizability).

Anyways, during the course of my usage I've come to the conclusion that it might be very helpful to have a de-structure flag. That is, a flag that takes a structured folder and returns a flattened version in which all the files are in the same folder at the same level. This is, of course, not useful for viewing the files, but it could be very useful for version control since keeping files in an unstructured way would eliminate file move base commit diffs.

The workflow I imagine, is keeping my local system formatted via destiny and using a git hook to de-structure my project before committing and re-structure my project on pull. I'd also, push the destiny config. So, when cloning to a new system I could re-structure the project.

The advantages to this are that each dev could structure their code how they like (assuming the structure can be generated programmatically), and version control diffs would be minimized to actual code changes. I realize that this would not be a workflow all destiny users would enjoy, but I expect, some would at least like to try it.

[AHBruns]

I should add I'd be happy to work on this feature. Also, I can reformat this issue if needed. I didn't find an issue template hence the lack of structure.

[AnatoleLucet]

That actually a really good idea. We all have our personal preferences when it comes to liting / prettification, this would easily able each dev to work with their own preferences on a common project.

This only is, what if two files are named the same way but in different folders? How can they both belong in the same folder with the same name when the structure is flatten?
We should find a solid way to flatten any kind of file tree.

[AnatoleLucet]

Maybe instead of having this flatten structure, Destiny could simply run with the default config? Then it would be easier to find files on the repo.

[AHBruns]

I think that’s a good simplified version of the idea and is probably worth implementing as a v1. However, it omits one of the big advantages which is preventing large diffs due to the the file structure changing drastically even though the code has only been changed a little.

I think, appending a deterministic UUID to file names on commit and stripping on pull could solve the duplicate name issue. To prevent the UUIDs from changing with the folder structure you’d probably want to base it off of its contents. This wouldn’t solve files with identical names and contents, but maybe that’s good since literal duplicates probably shouldn’t exist in a codebase (at least not in version control, maybe locally while working).

This is just my first instinct though. There may be much more elegant solutions.

[AHBruns]

As for keeping the remote readable, I’d push for a browser extension rather than storing a structured version since any programmatic file structure could have big changes due to small code changes.

[AHBruns]

The other option is just requiring users to uniquely name all their files. Apparently this is enforced at Facebook which seems like a decent signal.

Alternatively you could make longer and unique names (and even enforce those). This is what we do at FB and navigating a giant monorepo with just “jump to file” is great. I don’t even look at folders.

— Dan Abramov (@dan_abramov) April 23, 2020

[benawad]

Is there a reason you specifically want a flat structure to be stored in Git? Is it just for smaller diffs? Wouldn't Destiny using git mv solve that?

You could store the default Destiny structure in Git and then use a different config locally.

[AHBruns]

My only motivation for a flat structure is smaller diffs. I may be missing something obvious, but I'm not sure how git mv would play into this since, afaik, it's just an alias for mv oldname newname && git add newname && git rm oldname which means you're still causing diffs when moving files around. It seems like this is problematic because little code changes can cause destiny to output a very different file structure.

[benawad]

I dug into this a little bit and you're right, git mv still gives you a big diff unless you do --no-renames.

I'm not opposed to a de-structure flag then

[AHBruns]

Okay, I'll spend the next week getting familiar with the codebase, and try to have a PR open for a v1 of this feature in the next month or so. Sorry for the slow speed, I'm a student and have finals coming up in the next few weeks. Any input on how ya'll would like the API for this to look would be appreciated.

[AnatoleLucet]

No worries. There's no rush on that.
If you have any questions about how this could be implemented to Destiny you can come chat on Gitter 😉