-
Notifications
You must be signed in to change notification settings - Fork 326
docs: update 'corsEnabled' and explanation #680
Conversation
the existing documentation calls the property 'cors-enabled' but in actuality it's 'corsEnabled'
@oliemansm lemme know if there's anything I need to do to get this merged in 😘 |
I am not sure if updating the docs is the correct approach in this case.
I am not sure if this is the expected / intended behaviour. I would expect that if I disable a feature then it will remain disabled, even if some properties related to the disabled feature are present. |
Line 154 in 13cd484
Here
So in this case I think that the correct / "Spring-compliant" approach would be to change the property name to |
Changing the property name in the code seems reasonable, but it would be a breaking change. I am interested in contributing the change but am a first time contributor unfamiliar with the process for handling a breaking change. Is there a process for deprecating properties? A docs change would be a safer option, but if you think renaming the property is preferred then let’s go for it |
The next release is a major version (12.0.0) already coming with some breaking changes (e. g. a major starter reorganization) - so in this case this breaking change may also get a pass - but should be documented in the changelogs properly. Also, the commit may be marked as "breaking change" as described in the Conventional Commits specifications (https://www.conventionalcommits.org/en/v1.0.0/). I don't think it is possible to deprecate it properly (also, Checking other I would ask for a second opinion from @oliemansm on this topic, what would be the preferred approach. |
I agree that the kebab case is the preferred convention to be used. So it would be great @zjgoodman if you could make that so and use the breaking change commit message accordingly as @BlasiusSecundus mentioned. |
I've created a fix to support both versions of the property, so no more need for this PR. See: #732. |
the existing documentation calls the property
cors-enabled
but in actuality it'scorsEnabled
also added a disclaimer about the behavior of the underlying cors properties
Background
I came across this behavior while using the spring boot graphql playground. The playground submits a POST to
/graphql
but I was getting cors errors. For the sake of local testing, I figured I would just turn off cors headers. Looking at the docs, I setcors-enabled
tofalse
but that didn't do anything. Then I triedcorsEnabled
and that did work. You can also see looking at this repo's source code that the code itself is usingcorsEnabled
Method I used for testing this
Note that I am using
com.graphql-java-kickstart:graphql-spring-boot-starter:11.1.0
My graphql playground with cors enabled
Note that I am getting

Invalid CORS request
back from my spring boot app.My graphql graphql playground with cors disabled
I disabled cors using

corsEnabled: false
. Note that I am getting 200 OK back from my spring boot app