Improve support for custom files

[Vanisper]

Clear and concise description of the problem

1. When I want to customize files, if the filename is not the one preset in our project, then the updateFile will treat the file as plain text and execute the updateTextFile function.

https://github.com/antfu-collective/bumpp/blob/0583441364f09beeb254c460c4d1826f914e546a/src/update-files.ts#L35-L61

2. The execution logic of updateManifestFile and updateTextFile is completely different.

• updateManifestFile parses the file as JSON, and if the version field does not match the newVersion, it will execute the update logic. https://github.com/antfu-collective/bumpp/blob/0583441364f09beeb254c460c4d1826f914e546a/src/update-files.ts#L63-L94
• updateTextFile treats the file as plain text and will execute the update logic only if its content contains currentVersion. https://github.com/antfu-collective/bumpp/blob/0583441364f09beeb254c460c4d1826f914e546a/src/update-files.ts#L96-L124

---

But in fact, the customized file may also be a JSON file, and the field related to the version number may also be version. Of course, there may be customized requirements for the version number field.

In short, I want the non-preset files to be treated as JSON first, while also being compatible with the customized requirements for the version number field, and finally treated as plain text as a fallback logic.

Suggested solution

Provide the updateCustomFile function, which first treats the text as JSON, while also accommodating the need for a custom version number field.

If this is not feasible, it will be treated as plain text, which is the original updateTextFile function.

Alternative

No response

Additional context

I am willing to provide a PR for this.

By the way, we can even consider not being restricted to JSON files, at least supporting YAML, TOML, as per the requirement of #88.

Validations

• [x] Follow our Code of Conduct
• [x] Read the Contributing Guide.
• [x] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[Vanisper]

I realized that my thoughts were wrong, or unnecessary.

As a custom file, if it contains the current version number internally, there should be no problem using this as a matching condition.

But I still did some work, I maintained a "defaultFiles" for unified management of the default file configuration, and provided it outside the module.

I can expand "files" like this:

Also use this "defaultFiles" to do some small refactoring for the project, so that the file processing logic is unified.

Regarding the support for non-JSON files, I am still contemplating it, and the update will be posted here.

[Vanisper]

Regarding compatibility with non-JSON files, the core issue is to modify the text file while maintaining its original formatting.

The jsonc-parser has implemented the relevant lexical analysis, so it can achieve what was mentioned above. https://github.com/antfu-collective/bumpp/blob/0583441364f09beeb254c460c4d1826f914e546a/src/fs.ts#L44-L47

However, for other text parsing libraries of different formats, it is not always the case that the modify logic is implemented.

This involves lexical analysis, this is a troublesome matter; For example, there are some discussions about "smol-toml" regarding this issue.

---

About TOML, i am trying to do some implementations based on @toml-tools/parser, which is based on chevrotain.

During the implementation process, I used the strategy pattern to be compatible with other file types, but these strategies may all be based on chevrotain. I don't know if there is a better solution.

[antfu]

I think it's better for us to provide a onVersionUpdated callback option in the config, where the old and new versions are provided in the arguements, and user could do their own fs operation or even more in that function

[Vanisper]

Alright, this is a better approach 👍. However, due to work reasons, I may have to put my research on the current issue on hold for a while.

---

There is another question I would like to ask: ⬇️ Do you agree with the above implementation, because sometimes what I want is a supplement to the default configuration.

The implementation principle is just a unified management of this default configuration, the previous default configuration of the file list was not centrally managed, and the export for external use was done in passing.