What is the sanctioned way to extend Luxon's classes?

[cprecioso]

Hi! We have utility methods to encapsulate commonly used patterns with Luxon throughout our codebase (for example, making an Interval x minutes longer on both sides; or lowering the resolution of a DateTime to the closest quarter hour). The ideal way of using this for use would be as subclasses of these classes and using those in our code.

However, I can see that the static and instance methods do not respect subclassing and still return instances of Luxon's classes. Is there a specific extension facility to do this with? I was hoping I didn't have to end up modifying the prototype.

[icambron]

Yeah, Luxon's methods don't know about your subclasses, so without some sort of dependency injection system, those methods aren't going to be able to create instances of those subclasses.

IMO, modifying the prototype is the way to go. The risk is that one day Luxon adds a method with the same name and your code breaks, but that seems relatively unlikely, and if you are concerned about that, you could do some name prefixing.

[icambron]

No, wouldn't take that PR. "Subclassing support" really means dependency injection, since you need some way to register the constructors with Luxon so that Luxon can instantiate those subclasses. That creates a ton of new surface area to support, and I don't want to do that, especially if it's just to accomplish something that prototype modification (or just a wrapper function) does a fine job of. I'd basically be making the job of maintaining the library significantly harder in exchange for, as far as I can tell, not a lot of value for most developers

[cprecioso]

Yes, I get that. Thanks for the time taken in both responses! 😊

[baptiste00001]

No, wouldn't take that PR. "Subclassing support" really means dependency injection, since you need some way to register the constructors with Luxon so that Luxon can instantiate those subclasses. That creates a ton of new surface area to support, and I don't want to do that, especially if it's just to accomplish something that prototype modification (or just a wrapper function) does a fine job of. I'd basically be making the job of maintaining the library significantly harder in exchange for, as far as I can tell, not a lot of value for most developers

Hi,

I am not very experienced in typescript yet so the answer is probably 'no' but wouldn't making the constructor protected instead of private allow to extend the class?
I suppose that modifying the prototype works fine but just curious why using protected would give you more maintenance work.

Thank you in advance for your time.

[diesieben07]

The constructor doesn't have a good API surface. It is intended for Luxon's internal factory methods like for example DateTime.fromISO. What @icambron was saying is that for Luxon to have proper subclassing support, there would have to be a way for DateTime.fromISO (and all other factory methods) to return your subclass. But which one? How does Luxon know about it?

[baptiste00001]

I see.
I understand the issue now.
Thank you for your quick reply!

[sam-s4s]

Just in case anyone ends up here trying to find out how to do this... The answer by Yayo Arellano works well :)
https://stackoverflow.com/questions/67988216/luxon-datetime-adding-type-for-extension

import {DateTime} from 'luxon';

declare module 'luxon/src/datetime' {
    export interface DateTime {
        plusMillis(millis: number): DateTime;
    }
}

DateTime.prototype.plusMillis = function(millis: number): DateTime {
    const _self = this as DateTime;
    return _self.plus({milliseconds: millis});
};