Initial working version

[mansona]

This is essentially extracted directly from ember-cli https://github.com/ember-cli/ember-cli/blob/fb5ecc800a9ebd1dafbb6b475e3bdab72df276f6/lib/debug/deprecate.js along with its tests

[bertdeblock]

Cool, I was looking into doing the same thing.
Making a separate library for showing / handling (+ workflow) deprecations.
Though, personally, I would take the opportunity to e.g. update the API of deprecate.

type Deprecation = {
    for: string;
    id: string;
    message: string;
    since: { available: string; enabled?: string };
    until: string;
    url?: string;
};

function deprecate(deprecation: Deprecation): void

I think a deprecation should just be a single object, so including message with the rest of the information, so everything is grouped together. You can still override it when needed.

The message that is actually displayed should probably also be available somewhere. This would prevent issues like this.

Also, removing the condition argument. This has always been confusing for a lot of people. Having developers conditionally call deprecate is better I feel.

if (isUsingOldAPI) {
  deprecate(DEPRECATIONS.OLD_API);
}

Happy to help out if desired!

[mansona]

yea I'm happy to take this opportunity to change the API now, but I had a plan for this work 🤔 firstly I need it for embroider and it makes sense to split out the library, but I also don't like splitting out the library without also bringing the place you split it out from along for the ride: ember-cli/ember-cli#10610

now as I see it we have a few options:

• simplify the API for a nice library that can be used in multiple places and then wrap the use of it in ember-cli
• simplify the API and update all uses of it in ember-cli
• ship it as is for a 1.0 version and then simplify the library for a 2.0 (maybe even using semver-deprecate to manage itself 😂)
• something else

any preference or thoughts on the above?