feat(types): simplify Model definitions

[ephys]

Pull Request Checklist

• Have you added new tests to prevent regressions?
• Does yarn test or yarn test-DIALECT pass with this change (including linting)?
• Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?
• Did you update the typescript typings accordingly (if applicable)?
• Does the description below contain a link to an existing issue (Closes #[issue]) or a description of the issue you are solving?
• Did you follow the commit message conventions explained in CONTRIBUTING.md?

Description Of Change

Pretty large PR, it's a typing breaking change that makes InferAttributes the default way of handling attribute typing in v7.

So instead of writing:

class User extends Model<InferAttributes<User>, InferCreationAttributes<User>> {}

You now write:

class User extends Model<User> {}

---

Instead of writing:

interface UserAttributes {
  id: number;
  name: string;
}

interface UserCreationAttributes extends Optional<UserAttributes, 'id'> {}

interface UserInstance
  extends Model<UserAttributes, UserCreationAttributes>,
    UserAttributes {}

const UserModel = sequelize.define<UserInstance>('User', {
  id: {
    primaryKey: true,
    type: DataTypes.INTEGER.UNSIGNED,
  },
  name: {
    type: DataTypes.STRING,
  }
});

You now write:

interface IUserModel extends Model<IUserModel> {
  id: CreationOptional<number>;
  name: string;
}

const UserModel = sequelize.define<IUserModel>('User', {
  id: {
    primaryKey: true,
    type: DataTypes.INTEGER.UNSIGNED,
  },
  name: {
    type: DataTypes.STRING,
  },
});

---

Extra changes:

• Sequelize.define now uses InferAttributes too.
• InferAttributes & co are purely internal in v7, they are not exported anymore.
• Model['_attributes'] has been replaced with Model[AttributeSymbol] to prevent key collision in child models.
• Attributes<Model> now supports ModelStatic too! Usefull when used with Sequelize.define

The documentation has been updated to reflect this (as a result it's also much, much shorter)
The breaking change has been documented

[ephys]

So this is interesting! The same code that was breaking in #14032 is now breaking here. I'll continue on that other PR to find a solution

[WikiRik]

Is this part of one of the RFCs you proposed?

[ephys]

It was in my personal wishlist but I never opened an actual RFC for this breaking change
If there is any opposition or concerns, don't hesitate to talk about it in this PR :)

[WikiRik]

Ah, I read something about InferAttributes somewhere and was just curious. Will read into this more later but shorter in most cases is better so I'm happy about this

[ephys]

InferAttributes is the type I introduced in v6 a few weeks ago to reduce model typing boilerplate without causing a breaking change (#13909)

Since it looks like it's stable (I can't say how many people have used it yet, but it worked in my different projects), I'm going one step further and implementing that missing breaking change :)

[sdepold]

Simpler is always better, hm? :)

class User extends Model<User> {}

What is this User referring to? Another type? Or is the User class?

[sdepold]

Since I have never used this syntax before, I have no clue but I think one would have to call the Model's init function afterwards somehow?

Can you add that to the example?

[ephys]

What is this User referring to? Another type? Or is the User class?

Itself! It generates its attribute typings from its own class

[sdepold]

What is this User referring to? Another type? Or is the User class?

Itself! It generates its attribute typings from its own class

Pure magic! I love it!

[ephys]

I will draft this until #14125 has been resolved

---

We also need a way to define support for includes in Model.create, e.g. the following should not be an error:

class User extends Model<User> {
  declare groupId: number;
  declare group?: UserGroup;
}

await User2.create({
  id: 2,
  group: { id: 1 },
}, {
  include: [User.associations.group],
});

I think #14302 can help, and this is related to #14129

[ephys]

This PR has been in limbo for 2 months but it's blocked by #14302, which itself is blocked by #14280 (which in turn is blocked by #14333)

In the meantime I've replicated its non-blocked changes in #14333, to reduce the scope of this PR

[ephys]

I'll revisit this change when the rest of the project is ready for it