-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Docs: flat config files
/ ignores
function
#18118
Comments
I guess the docs need to be updated with the example.
I am not sure how to reframe the term |
The function forms of So my preference is to leave this as an undocumented feature. |
Question: why not just deprecate them and remove support entirely instead leaving hidden support? I've personally never seen anyone use the function form -- surely it's a tiny fraction of a fraction of the ecosystem that needs it. Very low usage paired with the downsides and maintenance burden of an increased surface area -- from my perspective it seems like a great candidate for removal. |
Investigating this more - it looks like the supported form of So the docs are even further from the truth than I thought! |
Yes, and there's a reason for that: if it's not documented, then it's not supported. That's always been the way we've handled documenting our APIs. I'm just not a fan of documenting stuff you're not allowed to use unless there's a replacement for it. @eslint/eslint-team I could use some other opinions on this. |
Should we fix the DefinitelyTyped types for eslint and remove the "unsupported" versions then so that people don't get the wrong idea? For context the types I had defined in @typescript-eslint just declared This meant that our flat config types could not accept a config defined with the DT types (because logically an array of functions and strings is incompatible with a target expecting an array of only strings). So I just had to land a change allow the unsupported types to fix a user pain point. I'd love to revert that though - but I can only do that if we change the DT types. |
Making sure I understand: is it accurate to say based on #18118 (comment):
If both of those are right then it seems reasonable to me that they can be marked as
I think that makes a lot of sense for regular docs (e.g. eslint.org). But there are some folks who rely on the undocumented, not-allowed |
Omitting this particular format from the documentation and annotating the type with I lean toward keeping the TypeScript type for it in place until the feature is actually removed, so as not to inhibit people from writing whatever TypeScript code they prefer. |
My big question would be "do we have any known usecases of these deprecated forms?" |
That aside. It's only the new flat configs that were declared with this deprecated form. And looking at the PR that added that type - the only reason that got added was because the person physically read the code from Given the old config form doesn't include the deprecated types, I propose that we update the flat config types to also not include the deprecated types. Nobody ever complained that the old types didn't include it so seems weird to add it to the new types just so we can mark it as |
I agree. "If it ain't documented, don't assume it exists even if you dig into the code." |
Oops! It looks like we lost track of this issue. What do we want to do here? This issue will auto-close in 7 days without an update. |
FWIW I'm in agreement with removing them. If they were never intended for public use, then that's a bug in |
There's general agreement that this should be considered a bug in |
Docs page(s)
https://eslint.org/docs/latest/use/configure/configuration-files-new
What documentation issue do you want to solve?
The docs for both
files
andignores
state:I.e. the docs state that the expected types are
files: Array<string>
andignores: Array<string>
However the flat config types [1] [2] specify that the two fields instead can also take functions.
I.e. the defined type is
type Spec = string | ((string) => boolean)
,files: Array<Spec>
andignores: Array<Spec>
.The function type was added in DefinitelyTyped/DefinitelyTyped#65530, which references the code for
@humanwhocodes/config-array
[3].I spent a bit grepping through this codebase but I can't find any tests for the function form.
So I'm not entirely sure what the correct state is here.
Is the function form of the fields an undocumented feature?
What do you think is the correct solution?
Should the types be updated to remove this or should the docs be updated to document this?
Participation
Additional comments
This was reported to us in @typescript-eslint by a user (typescript-eslint/typescript-eslint#8467) because our flat config types were defined based on what the docs specify (i.e. we define
Array<string>
).The text was updated successfully, but these errors were encountered: