Migrations and model definitions complains when using TEXT('long') on sqlite

I’m aware of:

https://github.com/sequelize/sequelize/pull/3836 https://github.com/sequelize/sequelize/pull/3839

but still don’t like https://github.com/sequelize/sequelize/pull/3839, IMHO is completely unnecesary, and at least there has to be a way to disable that behavior.

What you are doing?

Using SQLite adapter for development and MariaDB for staging/production, and defining an unlimited TEXT attribute:

description: {
      type   : Sequelize.TEXT('long')
    }

What do you expect to happen?

In SQLite, it should treat the attribute as a TEXT, and in MariaDB as a LONGTEXT, without complaining and triggering the error, since I think an ORM should do like jQuery did in the past, homogenize the same code and make easier changing the adapter without changing the code (among other thing, I know).

The funny thing is that it correctly translates the type according with the adapter, since was added in https://github.com/sequelize/sequelize/pull/3836, but it also triggers an annoying error/warning that IMHO it should not be doing.

What is actually happening?

It is triggering the following error/warning, preventing my app to start correctly:

error: >> WARNING: SQLite does not support TEXT with options. Plain `TEXT` will be used instead. 
>> Check: https://www.sqlite.org/datatype3.html
 module=core/db, stack=>> WARNING: SQLite does not support TEXT with options. Plain `TEXT` will be used instead. 
>> Check: https://www.sqlite.org/datatype3.html

Dialect: mysql / sqlite Sequelize version: 3.21.0

[j-m]

Would be nice to be able to silence this warning for dev and test environments. I use SQLite to run tests as it’s much faster and less memory intensive than other dialects. For obvious security reasons I use MySQL or PG for production environments.

[ephys]

We’re working on making all console output generated by Sequelize go through the log option that the Sequelize constructor accepts. (https://github.com/sequelize/sequelize/blob/main/src/dialects/abstract/index.ts#L420-L428)

Once that is done you’ll be able to mute any warning you want.

I must warn that perfect feature parity between dialects is not one of our goals and using a different dialects in prod VS in test can lead to bugs appearing in production. You’re of course still free to handle your tests any way you want.