Feature requests and suggestions

[ganapativs]

This tool has great potential. Here are some features I could think of.

• [ ] Resolving multiple files with the same extension(Not sure if it's already supported) If a folder has .js and .jsx and has been imported without extension, resolve order matters here. Make it configurable, optionally use butler.config.js?

• [ ] Watch mode?

  • Need to rethink performance issues as we are reading and modifying most of the files on every run
  • When to really move the file in watch mode? ‎

• [x] Dry run Potentially there will be too many folders/files movement, this might not be what the user always wants by default. There should be a way to see what happens before it actually happens. I could think of two options(Note: we already have information about this in the graph).

  • Print visual diff in the terminal before applying the changes(maybe too long for large projects)
  • Move files and folders and prompt user do you want to keep the changes, If no, revert the changes

These features are already suggested, but, re-adding here with a bit more context.

• [ ] Ignore directories/files/regex pattern Some tools like next.js and Gatsby depend on the folder structure. Allow skipping some of the folders and files(#11)

• [x] Support running programmatically Allow running via node(or any other tool) for flexibility. also, we might need some sort of config file like butler.config.js(oh, no, another config file?)(#8)

We can also have a GitHub project board where we can track progress. I'm really excited about the future of this project 🎉

[waynevanson]

Love what you have here.

My two cents on watch mode: I feel like this package should be part of a git workflow and not watch mode at all.

I would personally use this package only after my tree is clean and I'm about to push. Similar to how yarn publish will auto commit the bump of a version number in package.json.

Config files are gross, but what other options are there? We could just put them inline as CLI args in package.json. So destiny --arg-one value --arg-2-as-boolean

[sQVe]

@waynevanson I agree and think one of the major issues we need to solve is how to use destiny in a project using git or any other version control solution. Moving and renaming files can be such a hassle for merge conflicts.

I do not really envision destiny to be a tool that should run automatically but rather a tool that you run at specific times when you and your team members are all in sync.

[waynevanson]

@sQVe I just added to my comment if you'd like to see more.

Moving and renaming files can be such a hassle for merge conflicts.

Yeah that looks like a huge pain. I wonder what will be the solution.

In teams, it would be harder to use on an automatic basis. I agree with you.

[benawad]

We are using git mv, so I think that should prevent any merge conflicts related to the file being moved/renamed. Haven't tested that yet though, so not 100% sure.

[ganapativs]

We are using git mv, so I think that should prevent any merge conflicts related to the file being moved/renamed. Haven't tested that yet though, so not 100% sure.

There will be conflicts if the team/individual use squash and merge when merging. This should be added to FAQ probably.

Watch mode?

Also, I completely agree that probably there should not be a watch mode. Watch mode complicates things a lot and might not really be useful in most of the cases.

[benawad]

@ganapativs What would be the sequence of steps to replicate the conflict? Are you thinking: User 1 git move a file User 2 make a change in that file then squash, then pull User 1 changes

[ganapativs]

This probably should work(Needs testing)

User 1 git moves the file(say in fresh branch-1 from the master) User 2 edits the same file(in fresh branch-2 from the master, may be just editing the imports in the same file should work) User 2 squashes and merges his changes to master User 1 takes the pull(should probably get the conflict as User 2 changes history is lost when squashed)

Optionally, User 2 should get conflicts if User 1 changes are squashed and merged first.

This happened to me many times in large PRs, I expect it to happen here also.

[sQVe]

@ganapativs Squashing is not relevant in your example. Squashing problems will occur when you branch from a commit that later in time gets squashes - for example a feature branch that is based on another feature branch. What your example is explaining is just a simple merge conflict due to two parts changing the same thing. This is nothing that we'll be able to solve and will have to be handled manually.

What we do is make the merge conflicts easier by marking moved files as moved in Git.