Move settings methods to app.settings and deprecate old versions

[wesleytodd]

Started as a 5.x PR, this is the deprecation version for the 4.x branch. See: #3218

The only thing I am worried about this this is that the app.settings object has changed. It used to be a plain object, and is now an instance of Settings. I think some purists would call that a breaking change. The problem is that there is no way to provide the new functionality without changing that object.

If we had a faster major release cadence, we could deprecate in 5.0 (breaking direct .settings access) and remove in 6.0. But that might be YEARS, and speeding up majors is a different topic, one which I think we should do. So IMO I think we have two options:

1. Live with this as a breaking change in an undocumented api and release the deprecation warnings on the documented stuff
2. Only do this in 5.0.

I am perfectly happy with either, but if I had a choice it would be 1 because it preps people who are using it for 5.0 and the churn on this api shouldn't be much and is worth it.

[dougwilson]

The only thing I am worried about this this is that the app.settings object has changed. It used to be a plain object, and is now an instance of Settings. I think some purists would call that a breaking change. The problem is that there is no way to provide the new functionality without changing that object.

Ah, never realized that. Yea, it may not be possible to land this in 4 then. But I am on my phone so need to actually look at the changes later to get a better feel.

and speeding up majors is a different topic, one which I think we should do.

I've had similar thoughts recently and I agree it is a different topic, so won't even share my thoughts on this inline to keep on topic. If you would like to open a new discussion in the discussion repo, feel welcome!

I am perfectly happy with either, but if I had a choice it would be 1 because it preps people who are using it for 5.0 and the churn on this api shouldn't be much and is worth it.

Yea, I'll take a look both at the implementation and as much existing code that is out there to see if we will definitely break something or not as an additional point of reference.

[dougwilson]

I believe the last few minors had changes that were super subtle breaking changes that ended up having quick .1s each time to revert them because the age of express meant there was just massive usage of those subtle things because even when we don't document it, it gets in blogs, books, and stackoverflow, making it... difficult, haha.

[wesleytodd]

Release discussion: expressjs/discussions#67

And yeah the support issues is a big deal, and honestly one of the things you have done a great job with in express over the years. If we don't think it can land in 4 then it is fine, I can just add deprecation warnings that say it will be removed in 5.0. Of if that other discussion bares fruit, we can move to deprecate in 5.0 and remove in 6 :)

[wesleytodd]

Ok, this one is old and I think some more tests were added which were not in there when this was originally written. I am pretty sure that what is broken here is related to other changes which landed after the separate package was made. I am going to need to revisit that package first and then decide what to do here but I don't have time for that today as I am writing this on an airplane.

[wesleytodd]

Yeah at some point I decided to archive that repo since it was not moving forward. The more I think about it the more I am sure we dont need another package for this, but the changes to get rid of the overloading of .set are IMO good changes, and ones which if we don't land in v5 mean we cannot make them for a while. The PR is at least conflict free now, so if we decide to pick this back up it should be relativly easy to fix the behaviors needed to pass the new tests, I am just not sure that is the best idea.