Open JulianKniephoff opened 6 months ago
Nevermind, the enableVueSupport
thing was a fluke, I don't think the desired effect is possible at all at the moment.
Apologies for the confusion, a release for Vue compatibility is in the works but isn't quite ready to publish yet.
I think I understand your request; just to be clear, are you suggesting a configuration variation where, when a flag like "raw" is set and a string representing a comment node is provided, then a valid file might appear like below? I can explore implementing this, although I have a couple of concerns. One issue is that this leads to producing documentation that is less portable between projects/systems that may have different formatting standards; a file containing a JSDoc-style comment block cannot easily be reused in a Python project for example, as decoration and delimiters would need to be changed to conform to Python style guides. In a similar vein, this also introduces the possibility of formatting issues caused by human error, (e.g. decoration mismatches) that this rule considers "valid" but is visually inconsistent. Instead of fixing such an error by modifying a formatting configuration, the header content would need to be modified directly to fix the issue. This project strives to separate the enforced text content from a header's formatting rules, and creating a "raw" option creates an escape hatch to conflate these. That being said, I will think more on this and am open to discussing this further.
Example config:
{
// ...
rules: {
"headers/header-format": [
"error",
{
"raw": "true",
"type": "file",
"path": "LICENSE.txt"
},
],
},
}
LICENSE.txt
/**
* Copyright 2024. All rights reserved.
*/
Invalid source file:
export const magic = 42;
Valid source file
/**
* Copyright 2024. All rights reserved.
*/
export const magic = 42;
Your example looks like what I am suggesting, yes; thanks for considering it. 😊
Your concerns are valid, but especially regarding the first one I can just say that this plugin is not really all that usable in some mixed ecosystem projects at all, so portability isn't really a concern. I'm coming from a Java + JavaScript project, and the de facto standard Java linting mechanism to ensure file header consistency can't automatically add/infer comment characters. We are currently using this workaround to be able to share the header across ecosystems, but this is also prone to subtle errors, similar to the ones you mention in your second point.
I would also like to have this feature. I'm migrating a codebase from eslint-plugin-header
and currently can't match existing files with headers. I would prefer not to have a 3000 file commit to every file to be able to receive patches from upstream in the future.
It would be great if one could provide the header as-is, without this rule adding any comment formatting. This is kind of possible using the
enableVueSupport
option, but this isn't something only useful in Vue.In my project I have a header file that I also use with checkstyle, which doesn't/can't add the formatting itself, so it would be great if I could just reuse that here, and preferably without a comment explaining why I'm enabling Vue-support in a React project.