Add feature for external configuration of sortOrder

[neodon]

Hello,

Thank you for all the work you've done on this project. It solves an issue I've had for a long time around making my package.json files consistent, which is especially useful for diffing.

I'd like to propose a feature that will allow me to configure the sort order implicitly via an external config file, versus by using the API to do it explicitly.

I'm also interested in contributing to this project. So if you are willing to accept such a feature, I can probably do the work.

• It is possible to call sortPackageJson(packageJson, options?) without an options argument that specifies sortOrder. In this case sorting will be done according to defaultSortOrder.
• I'd like for sortOrder to be configurable by other means, such as an external configuration file. Note: The key and file names are only suggestions.
  • Via a sortPackageJson key in package.json. Example:

    "sortPackageJson": {
    "sortOrder": ["name", "version", "type"]
    }

  • Via a config file in the same directory as package.json, such as .sort-package-json.json (or without the preceding dot). Example:

    {
    "sortOrder": ["name", "version", "type"]
    }

• The external configuration file would be used any time sortPackageJson is called without an options.sortOrder argument, including usage via the API or CLI. This would allow the VSCode extension to use custom sorting without updating the extension code.
• The default sort order would still apply after considering the explicit sort order, preserving the current behavior.

The above is the basic feature and probably the first step. As an addition to the feature, what would be your thoughts about having more granular control for overriding the defaults? For example, if sortOrder is specified as an object:

{
  "sortOrder": {
    "mocha": { "before": "prettier" },
    "prettier": { "after": ["eslintConfig", "eslintIgnore"] }
  }
}

The before and after values would be more like recommendations to the sorting algorithm, instead of being explicit directives to put something directly before or directly after the given keys. For example, as long as mocha appears before prettier, there could be other things between them.

Thank you for considering.

[keithamus]

Hi @neodon thanks for the issue.

I'd like to know the motivations use case for adding configuration.

If it's to add new keys, I think we're responsive enough to those changes.

If it's to change the order of a key, this has been changed before and we can discuss that in more detail.

A lot of people who ask for configuration cite the use case that they simply don't like the given order that exists and want to make sweeping changes. To me this seems far better suited to simply making a fork of this project as then you can go far further than specifying configuration.

I don't wish for this project to have any configuration whatsoever. I think the reason why this project is well used is because it is not another "tool" you have to set up with yet another JSON file and more cruft in your project to support it. You run a command and it does what it says on the tin.

I also worry that if we do introduce configuration the complexity of the code base will sky rocket. I don't think we need this codebase to be any more complex than it is already.

I also think having the sort order configurable breaks one of the key features of this project, which is that the file structure of the package.json is predictable from project to project. For example the name key is always first and I can just take the 2nd line of the file and know that contains the package name. If we have configurable sort orders then I can't switch between 10 different projects and always guarantee that the name will be on line 2 of the json.

---

Because of the reasons above I'm going to close this issue. If you disagree we can continue the conversation, but as stated above I'd like to start from a place of motivation: what is the problem that you're trying to solve. What is the intent of the solution here?

[neodon]

Thank you for the quick response and the candor. My goal was to have a custom sort order that I could apply to all of my own projects. I will take your advice and make a fork for my own use. I agree it's a much simpler solution, especially given the principles you cited for zero config and keeping this codebase simple.