cli
cli copied to clipboard
sequelize
Add TypeScript support
Since coffeescript is supported, i think it would be cool to have a typescript support also.
Expectation:
run node_modules/sequelize-cli/bin/sequelize model:create --name Collection --attributes id:integer,name:string --typescript
Will produce a model which ends in '.ts' instead of '.js'.
Justification: In projects where typescript is used, javascript files are sometimes ignored (because they are produced through typescript). Therefore, the model will be ignored by default. Afterwards, a developer must edit the model/migration.
Result: Tiny bit of work removed when developing with typescript.
The problem I see here is that the pattern I found to be the best for TypeScript is totally different than the approach sequelize-cli uses. The pattern of the exported closure and a static associate() method is really hard to type (how do you type the models parameter?). Using late imports works much better.
Does "Add TypeScript support" also include generating migrations? If so the only change there is to save the file as .ts instead of .js.
Well, putting just .ts instead of .js as suffix would do the job in terms of a TypeScript file is created. Additionally, i would expect, that the class syntax of TypeScript would be supported and the typings for properties.
class Test {
private someNumber: number;
private someString: string;
public function setSomeNumber(myNumber: number): void {
this.someNumber = myNumber;
}
public function getSomeNumber(): number {
return this.someNumber;
}
...
}
Sorry, you are right. Thought about another thing. Regarding the TypeScript, it would be sufficient to have the .ts ending and some TypeScript syntax (lambda functions, ...).
Another feature would be to have the classes above instead of the current syntax: I can define the above class, it will be derived from a sequlize-parent-model (or something). Afterwards this class is scanned for its properties etc. This thing would go into the direction of EntityFramework (C#) and Hibernate (Java).
You are thinking about models, not migration files. A migration file just exports two functions, up and down.
+1 to this. Actually it should look not simply as file saved with .ts extension, but contain a slightly different contents in it, for example:
import { QueryInterface } from 'sequelize';
import { DataType } from 'sequelize-typescript';
export async function up(query: QueryInterface) {
/*
Add altering commands here.
Example:
await query.createTable('users', { id: DataType.INTEGER });
console.log('Table users created!');
*/
}
export async function down(query: QueryInterface) {
/*
Add reverting commands here.
Example:
await query.dropTable('users');
console.log('Table users dropped!');
*/
}
So:
- it should save with different extension
- it should put different contents inside....
Maybe it's even better to provide those possibilities in more generic way, like add an ability to provide user-defined template for those files. An I will be able to construct myself which dialect of javascript I use...
@Mikhus YES! Native module support is required. The nice thing about your sample code is that you only introduce TypeScript to utilize QueryInterface. 👍
Please don't +1 issues. It clutters the thread without adding value to the discussion and spams maintainers with notifications. Use GitHub reactions to upvote features.
@felixfbecker I have not used it in a project (but am planning to on mynext project), but have you seen the [sequelize-typescript)[https://github.com/RobinBuschmann/sequelize-typescript] project - it looks like a really interesting way of making Sequelize a bit more typescripty...
I am not sure if that makes the generated application prescribe a package that people might not be familiar with / want.
Another option would be to treat the models directory as a package, and instead of generating different code for typescript, just generating the declaration files.
This might look something like:
Directory Structure
models/
index.js
index.d.ts
package.json
user.js
user.d.ts
package.json
{
"name": "create-observable-thunk",
"main": "./index.js",
"typings": "./index.d.ts",
}
types.d.ts
import * as Sequelize from "sequelize"
export const Sequelize: Sequelize
export const sequelize: Sequelize.Sequelize
export default namespace db {
}
user.d.ts
import * as Sequelize from "sequelize"
interface Attributes {
// ...
}
export default namespace db {
Cat: Sequelize.Model
}
Note I haven't made sure these typings made sense.
Until sequelize-cli has a TypeScript support option, the people on this thread may want to check out https://github.com/douglas-treadwell/sequelize-cli-typescript. (Note that it is already available on NPM.). I forked sequelize-cli and made a version that outputs TypeScripts (including migrations). See the README section "Differences...", but otherwise it works like regular sequelize-cli and should be a drop-in replacement.
Also, by looking at the changes in my fork the maintainers of sequelize-cli or other contributors may be able to notice what sort of changes would be needed to support TypeScript in the mainline project.
checkout this package which may help you to make typescript models and ease out models initialization https://www.npmjs.com/package/ts-sequelize-models
I would request that instead of --typescript we would have --generatedExtension ts
If coupled with registering transformations based on extension, we could support output in coffeescript, livescript, es6, etc
I assume the opinion has changed here since Sequelize 5 exports TypeScript types and could be of some value here. Would love type hints when writing my migrations as it's currently trial and error as the documentation often just says: "object" for options
It seems that there has been no progress on this requirement, so does anyone knows a reliable way to perform migrations with TS?
I'd better opt to migrate to Typeorm, since this library looks like this library is continuously ignoring Typescript support.
@virgenherrera It doesn't make any sense to ignore it (if they seriously are). To work with databases and not to use TypeScript (which enforces types) seems rather ridiculous IMO.
We're hard at work at improving TypeScript support for the main repo and we'll work on CLI after we've done most of our planned changes. v7 will have much better TypeScript support but we're open to PRs of the community in the meantime
