[question] Support other formats
Closed this issue · 5 comments
Cool work. Do you mind supporting other formats, like javascript's package.json, rust's cargo.toml? That is separate the logic of reading configurations to a separate file like pyproject.py, package.py, ..., And keep common code in __init__.py.
If you agree to separate the code to common code of __init__.py and pyproject.py, we can add PR to support more config formats. If not, I think we must add many projects like mdformat-package, mdformat-cargo, ... and they must copy common code from this project?
@Freed-Wu Support for other file standards would be great, but I'm not sure this would be the right place.
This plugin is specifically named after pyproject, so I think it is makes sense to not expand the scope to anything other than pyproject.toml. Instead, for the other files I would create specific plugins for each one, mdformat-package, mdformat-cargo, etc. so every project can include only the format they need for their file type.
Hey, I know the name of this project is mdformat-pyproject. Changing name is not essential. We can add keywords about package.json and cargo.toml to let user find it.
If we create new projects named mdformat-pacakge, mdformat-cargo, it will have many same code as mdformat-pyproject. I think it is not necessary. No need to copy same code to many similar projects. And if a bug is found in copied code, all mdformat-* should be updated to fix it. It is more troublesome. Just my 2c.
It looks like package.json, cargo.toml doesn't have any properties like pyproject.toml's tool.
eslint and prettier use their .eslintrc, .prettierrc.
The only exception is eslint support package.json's eslintConfig, which is not standard.
https://eslint.org/docs/latest/use/configure/configuration-files#configuration-file-formats