TypeScript: Javascript: Object.assign to assign property values for classes is not respected

Came here from #28883. I understand that in the general case, the type of the second argument to Object.assign could be of type any, but in my specific case I define that type via an interface beforehand:

interface MyConfig {
    someConfigProp: boolean;
}
class MyClass implements MyConfig {
    // Error: Property 'someConfigProp' has no initializer
    // and is not definitely assigned in the constructor.
    someConfigProp: boolean;
    constructor (config: MyConfig) {
        Object.assign(this, config);
    }
}

It seems to me that comparison between the types of this and config could be done, and if config is some type that’s not assignable to this, then that would be the condition where you couldn’t determine the type.

The alternative right now is to manually assign every property of the config interface to the corresponding class property, which works but is a pain:

interface MyConfig {
    someProp: boolean;
    someOtherProp: string;
    // ...etc
}
class MyClass implements MyConfig {
    someProp: boolean;
    someOtherProp: string;
    // ...etc
    constructor (config: MyConfig) {
        this.someProp = config.someProp;
        this.someOtherProp = config.someOtherProp;
        // ...repeated for every property of the config object
    }
}

(This whole thing gets even more ugly when dealing when using optional properties on the config object to allow the use of default values:

interface MyConfig {
    // these props are optional in the config object
    someProp?: boolean;
    someOtherProp?: string;
}
class MyClass implements MyConfig {
    // all props are required in the class, with default values
    someProp: boolean = false;
    someOtherProp: string = 'default value';
    constructor (config: MyConfig) {
        if (config.someProp !== undefined)
            this.someProp = config.someProp;
        if (config.someOtherProp !== undefined)
            this.someOtherProp = config.someOtherProp;
    }
}

and as you can see, with lots of properties on the config object, you quickly wind up with a large chunk of code that just does the same job Object.assign normally does, as it automatically handles optional properties. However, because Object.assign interprets a key with value undefined as present, this would be blocked on #13195 for full compatibility.)

Is there any way to achieve this right now? If not, is it viable to implement? I could look into putting a PR together, but no promises as I’ve never worked with TS’s source before.

Why not support return different thing from constructor()?

class X {
	public X: number;

	constructor() {
		return new Y;
	}
}

class Y extends X {
	public Y: number;
}

const obj = new X;
console.log(obj.Y); /// TS2339: Property 'Y' does not exist on type 'X'

It’s more common than only Object.assign.

Not quite, though… The issue was never that the arguments were improperly typed, but that the Object.assign call doesn’t update which properties are present on its first argument, in this case the constructed instance.

Maybe a better example:

interface MyOptions {
   myRequiredProp: string;
}
class MyClass implements MyOptions {
    myRequiredProp: string;
    constructor (options: MyOptions) {
        // The next line guarantees myRequiredProp is assigned, since
        // it's required on MyOptions
        Object.assign(this, options);
        // Next line generates "Property 'myRequiredProp' is used
        // before being assigned"
        if (this.myRequiredProp === 'some value') {
            // additional setup here
        }
    }
}

I came across a similar issue where I wanted to essentially extend a type from a third-party library, but didn’t want to manually write out all of the properties (lazy 😅). This is what I ended up doing:

Create class from a generic type:

function createClassFromType<T>() {
  return class {
    constructor(args: T) {
      Object.assign(this, args)
    }
  } as ({
    new (args: T): T
  })
}

Create a base class for my Person type:

type Person = {
  name: string
}

const PersonClass = createClassFromType<Person>()

const person = new PersonClass({ name: 'Alice' })

person.name // Alice

Extending PersonClass is also very easy:

class MyPerson extends PersonClass {
  constructor(person: Person) {
    super(person)
  }
  greet() {
    console.log(`Hello, ${this.name}`)
  }
}

Here are some more example use cases:

const classPerson = new PersonClass({ name: 'Alice' })
console.log(classPerson.name)   // Alice

const childPerson = new PersonChild({ name: 'Bob' })
childPerson.greet()   // "Hello, Bob!"

function doSomethingWith(personType: Person) {
  // example method only acceots person type
}

doSomethingWith(classPerson)  // this is ok!
doSomethingWith(childPerson)  // this is ok!

if (childPerson instanceof PersonClass) {
  console.log('person is instanceof PersonClass!')
}

if (childPerson instanceof PersonChild) {
  console.log('person is instanceof MyPerson!')
}

Check it out on the TypeScript playground!

What I ended up doing in my case was to merge/augment the class with an interface like below. This is not a solution to the problem but a workaround.

The idea is to have an interface that defines the object passed to the constructor function that has the same name as the class.

export interface Awesome {
  x: string;
  y: number;
  z: boolean;
  zz?: boolean;
}

export class Awesome {
  constructor(props: Awesome) {
    Object.assign(this, props);
  }

  fn() {
    return this.x; // TS finds x on this because of the interface above.
  }
}

If you have a base abstract class that you want to use together with generics to dynamically defines class properties, you can do this:

// eslint-disable-next-line @typescript-eslint/no-empty-interface, @typescript-eslint/interface-name-prefix
export interface BaseAwesome<T extends IBaseAwesomeProps> extends IBaseAwesomeProps {}

export abstract class BaseAwesome<T extends IBaseAwesomeProps> {
  constructor(props: T) {
    Object.assign(this, props);

    // Some contrived logic to show that both "this" and "props" objects contain the desired object properties.
    this.y = props.y > 5 ? 5 : props.y;
  }

  getX(): T['x'] {
    return this.x;
  }

  updateX(x: T['x']) {
    this.x = x;
  }

  abstract logZZ(): void;
}

Then the abstract class can be used like this:

export interface IDerivedAwesomeProps extends IBaseAwesomeProps {
  someNewProp: 'this' | 'that'; // new prop added on top of base props.
  xx: number; // modified base prop to be required and have specific type.
}

export class DerivedAwesome extends BaseAwesome<IDerivedAwesomeProps> {
  logZZ() {
    console.log(this.zz);
  }
}

const awesomeInstance = new DerivedAwesome({
  someNewProp: 'that',
  x: 'some string value',
  xx: -555,
  y: 100,
  z: true,
});

console.log(awesomeInstance.getX()); // -> some string value
awesomeInstance.logZZ(); // -> undefined

I’ve been looking for this for a while and your solution @asleepace is perfectly doing the job!

By directly calling the createClassFromType method when declaring the actual class most of the boilerplate is avoided:

function classFromProps<T>() {
    return class {
        constructor(props: T) {
            Object.assign(this, props);
        }
    } as ({new (args: T): T});
}

type PersonProps = {
    firstname: string,
    lastname: string,
};

class Person extends classFromProps<PersonProps>() {
    get fullname() {
        return [this.firstname, this.lastname].join(' ');
    }
}

const ts = new Person({firstname: 'Tom', lastname: 'Smith'});

console.log(ts);           // ==> Person: {"firstname": "Tom", "lastname": "Smith"} 
console.log(ts.fullname);  // ==> "Tom Smith"

@PLSFIX This helps somewhat for users of the class, but if class methods use any of the properties of Opts they would still have to be declared as fields, and to have them as readonly the compiler would still complain that they are “definitely not assigned in the constructor”. So your solution obviously doesn’t help making those properties fields.

If we could have field designators (public/private/protected + readonly) in destructured object parameters this problem would be solved AND we would have the added bonus of being able to initialize parts of an object automatically without having to use Object.assign at all:

interface Opts {
  a: string;
  b: number;
}

export class SomeClass implements Opts {
  constructor({readonly a, readonly b}: Opts) {
  }
}

This would be amazing. Right now, if you want to augment a POJO with some methods, say, for computing related values, it’s really easy to do in JS — but basically impossible to type in TS without a lot of boilerplate or circular reference issues:

class AugmentedPOJO {
  a() { return this.b(); },
  b() { return this.x; }
  constructor(pojo: { x: string }) {
    // doesn't work, as pointed out 
    Object.assign(this, pojo);
  }
}

If we want to guarantee that the new methods (a and b) won’t be shadowed by an own prop of the pojo, we could do something in vanilla JS like:

function augment(pojo) {
  return { ...pojo, ...methods };
}

const methods = { 
  a() { return this.b(); },
  b() { return this.x; }
}

But trying to type the this for the functions on the methods objects (which should be { x: string } & typeof methods) blows up with circularity errors that are only avoided when using a class.

The best hack I’ve come up with is:

type Pojo = { x: string };
type AugmentedTrueType = Pojo & _Augmented;

class _Augmented {
  constructor(pojo: Pojo) {
     object.assign(this, pojo);
  } 
  a(this: AugmentedTrueType) { return this.b(); }
  b(this: AugmentedTrueType) { return this.x; }
}

const Augmented = _Augmented as {
  new (pojo: Pojo): AugmentedTrueType;
};

// Works as expected!
const a = new Augmented({ x: "hello" });

Just found this article which outlines a way to accomplish this with the return value of Object.assign(), but doesn’t address performing the in-place operation/modifying the type of the first argument without reassignment. https://spin.atomicobject.com/2018/05/14/type-safe-object-merging-2-8/

I’m interested in making a PR for this behavior; does anyone more familiar with the project have any pointers on possible starting points?

Actually, it might not be possible to support this feature for ambiguous objects.

E.g.

Object.assign(this, obj1);

Since obviously obj1 can be of any type in JS; hence there is no way to find out what is being assigned to this.

But I think it would be a good idea to be able to support explicit assignment to this with Object.assign.

Any solution except TypeScript itself handling this will be an ugly workaround. Using a class declaration wrapper function every time we want to declare a class is just hideous. Yes, it works, but so does resorting to any or going other pointless routes that don’t really address the problem.

A workaround solution I used was to create a type alias for the base class. Something like:

interface Opts {
  a: string;
  b: number;
}
export class SomeClass {
  constructor(opts: Opts) {
    Object.assign(this, opts);
  }
}

export type TSomeClass = SomeClass & Partial<Opts>;

At least you get intellisense tips and typechecking

Next line generates “Property ‘myRequiredProp’ is used before being assigned”

You could get around that with a definite assignment assertion (!), but it would be nice if TypeScript could figure that out instead.