Creating a new table in migration creates an extra index automatically

What are you doing?

Creating a table.

'use strict';
module.exports = {
  up: (queryInterface, Sequelize) => {
    return queryInterface.createTable('gloss_gloss', {
      glossId: {
        primaryKey: true,
        allowNull: false,
        type: Sequelize.INTEGER,
        references: {model: 'glosses', key: 'id'},
        onUpdate: 'CASCADE',
        onDelete: 'CASCADE'
      },
      alt_glossId: {
        primaryKey: true,
        allowNull: false,
        type: Sequelize.INTEGER,
        references: {model: 'glosses', key: 'id'},
        onUpdate: 'CASCADE',
        onDelete: 'CASCADE'
      },
      createdAt: {
        allowNull: false,
        type: Sequelize.DATE
      },
      updatedAt: {
        allowNull: false,
        type: Sequelize.DATE
      }
    });
  },
  down: (queryInterface, Sequelize) => {
    return queryInterface.dropTable('gloss_gloss');
  }
};

What do you expect to happen?

I wanted the table to have a primary key with no other key/indices.

What is actually happening?

The table has an extra index I never specified.

Dialect: MySQL

DROP TABLE IF EXISTS `gloss_gloss`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `gloss_gloss` (
  `glossId` int(11) NOT NULL,
  `alt_glossId` int(11) NOT NULL,
  `createdAt` datetime NOT NULL,
  `updatedAt` datetime NOT NULL,
  PRIMARY KEY (`glossId`,`alt_glossId`),
  KEY `alt_glossId` (`alt_glossId`),
  CONSTRAINT `gloss_gloss_ibfk_1` FOREIGN KEY (`glossId`) REFERENCES `glosses` (`id`) ON DELETE CASCADE ON UPDATE CASCADE,
  CONSTRAINT `gloss_gloss_ibfk_2` FOREIGN KEY (`alt_glossId`) REFERENCES `glosses` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;

Specifically, I'm seeing KEY `alt_glossId` (`alt_glossId`), which I don't think should happen.

Start by reproducing the supplied queryInterface.createTable migration against MySQL and inspect the generated CREATE TABLE statement. Trace the createTable handling from that entry point to determine why the foreign-key column receives an index; done means the composite primary key remains while the unspecified alt_glossId KEY is absent.