Security News
Weekly Downloads Now Available in npm Package Search Results
Socket's package search now displays weekly downloads for npm packages, helping developers quickly assess popularity and make more informed decisions.
A very small TypeScript library that provides tolerable Mixin functionality.
The ts-mixer package is a TypeScript library that provides utilities for creating mixins and multiple inheritance in TypeScript. It allows developers to combine multiple classes into one, enabling more flexible and reusable code structures.
Basic Mixin
This feature allows you to create a new class that combines the methods and properties of multiple classes. In this example, class C inherits methods from both class A and class B.
const { Mixin } = require('ts-mixer');
class A {
methodA() {
console.log('Method A');
}
}
class B {
methodB() {
console.log('Method B');
}
}
class C extends Mixin(A, B) {}
const c = new C();
c.methodA(); // Method A
c.methodB(); // Method B
Advanced Mixin with Constructor
This feature demonstrates how to handle constructors when mixing classes. The new class C can initialize properties from both class A and class B.
const { Mixin } = require('ts-mixer');
class A {
constructor(public name: string) {}
methodA() {
console.log(`Method A: ${this.name}`);
}
}
class B {
constructor(public age: number) {}
methodB() {
console.log(`Method B: ${this.age}`);
}
}
class C extends Mixin(A, B) {
constructor(name: string, age: number) {
super(name, age);
}
}
const c = new C('John', 30);
c.methodA(); // Method A: John
c.methodB(); // Method B: 30
Mixin with Interfaces
This feature shows how to use mixins with interfaces. Class C implements both IA and IB interfaces and inherits methods from class A and class B.
const { Mixin } = require('ts-mixer');
interface IA {
methodA(): void;
}
interface IB {
methodB(): void;
}
class A implements IA {
methodA() {
console.log('Method A');
}
}
class B implements IB {
methodB() {
console.log('Method B');
}
}
class C extends Mixin(A, B) implements IA, IB {}
const c = new C();
c.methodA(); // Method A
c.methodB(); // Method B
The mixwith package provides a similar functionality for creating mixins in JavaScript and TypeScript. It offers a more flexible and modern approach to mixins, but ts-mixer is more TypeScript-centric and provides better type safety.
The mixin-deep package allows deep merging of objects and mixins. While it is more focused on object merging rather than class-based mixins, it can be used to achieve similar results in a different way.
Lodash is a utility library that provides a wide range of functions, including mixin capabilities. However, it is more general-purpose and not specifically designed for TypeScript or class-based mixins.
ts-mixer
brings mixins to TypeScript. "Mixins" to ts-mixer
are just classes, so you already know how to write them, and you can probably mix classes from your favorite library without trouble.
The mixin problem is more nuanced than it appears. I've seen countless code snippets that work for certain situations, but fail in others. ts-mixer
tries to take the best from all these solutions while accounting for the situations you might not have considered.
ts-mixer
instanceof
-like replacement (with caveats [5, 6]).apply(...)
on class constructors (or any means of calling them without new
), which makes it impossible for ts-mixer
to pass the proper this
to your constructors. This may or may not be an issue for your code, but there are options to work around it. See dealing with constructors below.ts-mixer
does not support instanceof
for mixins, but it does offer a replacement. See the hasMixin function for more details.@dectorator
and hasMixin
) make use of ES6 Map
s, which means you must either use ES6+ or polyfill Map
to use them. If you don't need these features, you should be fine without.$ npm install ts-mixer
or if you prefer Yarn:
$ yarn add ts-mixer
import { Mixin } from 'ts-mixer';
class Foo {
protected makeFoo() {
return 'foo';
}
}
class Bar {
protected makeBar() {
return 'bar';
}
}
class FooBar extends Mixin(Foo, Bar) {
public makeFooBar() {
return this.makeFoo() + this.makeBar();
}
}
const fooBar = new FooBar();
console.log(fooBar.makeFooBar()); // "foobar"
Abstract classes, by definition, cannot be constructed, which means they cannot take on the type, new(...args) => any
, and by extension, are incompatible with ts-mixer
. BUT, you can "trick" TypeScript into giving you all the benefits of an abstract class without making it technically abstract. The trick is just some strategic // @ts-ignore
's:
import { Mixin } from 'ts-mixer';
// note that Foo is not marked as an abstract class
class Foo {
// @ts-ignore: "Abstract methods can only appear within an abstract class"
public abstract makeFoo(): string;
}
class Bar {
public makeBar() {
return 'bar';
}
}
class FooBar extends Mixin(Foo, Bar) {
// we still get all the benefits of abstract classes here, because TypeScript
// will still complain if this method isn't implemented
public makeFoo() {
return 'foo';
}
}
Do note that while this does work quite well, it is a bit of a hack and I can't promise that it will continue to work in future TypeScript versions.
Frustratingly, it is impossible for generic parameters to be referenced in base class expressions. No matter what, you will eventually run into Base class expressions cannot reference class type parameters.
The way to get around this is to leverage declaration merging, and a slightly different mixing function from ts-mixer: mix
. It works exactly like Mixin
, except it's a decorator, which means it doesn't affect the type information of the class being decorated. See it in action below:
import { mix } from 'ts-mixer';
class Foo<T> {
public fooMethod(input: T): T {
return input;
}
}
class Bar<T> {
public barMethod(input: T): T {
return input;
}
}
interface FooBar<T1, T2> extends Foo<T1>, Bar<T2> { }
@mix(Foo, Bar)
class FooBar<T1, T2> {
public fooBarMethod(input1: T1, input2: T2) {
return [this.fooMethod(input1), this.barMethod(input2)];
}
}
Key takeaways from this example:
interface FooBar<T1, T2> extends Foo<T1>, Bar<T2> { }
makes sure FooBar
has the typing we want, thanks to declaration merging@mix(Foo, Bar)
wires things up "on the JavaScript side", since the interface declaration has nothing to do with runtime behavior.mix
decorator is that the typing produced by Mixin(Foo, Bar)
would conflict with the typing of the interface. mix
has no effect "on the TypeScript side," thus avoiding type conflicts.Popular libraries such as class-validator and TypeORM use decorators to add functionality. Unfortunately, ts-mixer
has no way of knowing what these libraries do with the decorators behind the scenes. So if you want these decorators to be "inherited" with classes you plan to mix, you first have to wrap them with a special decorate
function exported by ts-mixer
. Here's an example using class-validator
:
import { IsBoolean, IsIn, validate } from 'class-validator';
import { Mixin, decorate } from 'ts-mixer';
class Disposable {
@decorate(IsBoolean()) // instead of @IsBoolean()
isDisposed: boolean = false;
}
class Statusable {
@decorate(IsIn(['red', 'green'])) // instead of @IsIn(['red', 'green'])
status: string = 'green';
}
class ExtendedObject extends Mixin(Disposable, Statusable) {}
const extendedObject = new ExtendedObject();
extendedObject.status = 'blue';
validate(extendedObject).then(errors => {
console.log(errors);
});
As mentioned in the caveats section, ES6 disallowed calling constructor functions without new
. This means that the only way for ts-mixer
to mix instance properties is to instantiate each base class separately, then copy the instance properties into a common object. The consequence of this is that constructors mixed by ts-mixer
will not receive the proper this
.
This very well may not be an issue for you! It only means that your constructors need to be "mostly pure" in terms of how they handle this
. Specifically, your constructors cannot produce side effects involving this
, other than adding properties to this
(the most common side effect in JavaScript constructors).
If you simply cannot eliminate this
side effects from your constructor, there is a workaround available: ts-mixer
will automatically forward constructor parameters to a predesignated init function (settings.initFunction
) if it's present on the class. Unlike constructors, functions can be called with an arbitrary this
, so this predesignated init function will have the proper this
. Here's a basic example:
import { Mixin, settings } from 'ts-mixer';
settings.initFunction = 'init';
class Person {
public static allPeople: Set<Person> = new Set();
protected init() {
Person.allPeople.add(this);
}
}
type PartyAffiliation = 'democrat' | 'republican';
class PoliticalParticipant {
public static democrats: Set<PoliticalParticipant> = new Set();
public static republicans: Set<PoliticalParticipant> = new Set();
public party: PartyAffiliation;
// note that these same args will also be passed to init function
public constructor(party: PartyAffiliation) {
this.party = party;
}
protected init(party: PartyAffiliation) {
if (party === 'democrat')
PoliticalParticipant.democrats.add(this);
else
PoliticalParticipant.republicans.add(this);
}
}
class Voter extends Mixin(Person, PoliticalParticipant) {}
const v1 = new Voter('democrat');
const v2 = new Voter('democrat');
const v3 = new Voter('republican');
const v4 = new Voter('republican');
Note the above .add(this)
statements. These would not work as expected if they were placed in the constructor instead, since this
is not the same between the constructor and init
, as explained above.
As mentioned above, ts-mixer
does not support instanceof
for mixins. While it is possible to implement custom instanceof
behavior, this library does not do so because it would require modifying the source classes, which is deliberately avoided.
You can fill this missing functionality with hasMixin(instance, mixinClass)
instead. See the below example:
import { Mixin, hasMixin } from 'ts-mixer';
class Foo {}
class Bar {}
class FooBar extends Mixin(Foo, Bar) {}
const instance = new FooBar();
// doesn't work with instanceof...
console.log(instance instanceof FooBar) // true
console.log(instance instanceof Foo) // false
console.log(instance instanceof Bar) // false
// but everything works nicely with hasMixin!
console.log(hasMixin(instance, FooBar)) // true
console.log(hasMixin(instance, Foo)) // true
console.log(hasMixin(instance, Bar)) // true
hasMixin(instance, mixinClass)
will work anywhere that instance instanceof mixinClass
works. Additionally, like instanceof
, you get the same type narrowing benefits:
if (hasMixin(instance, Foo)) {
// inferred type of instance is "Foo"
}
if (hasMixin(instance, Bar)) {
// inferred type of instance of "Bar"
}
ts-mixer has multiple strategies for mixing classes which can be configured by modifying settings
from ts-mixer. For example:
import { settings, Mixin } from 'ts-mixer';
settings.prototypeStrategy = 'proxy';
// then use `Mixin` as normal...
settings.prototypeStrategy
'copy'
(default) - Copies all methods from the classes being mixed into a new prototype object. (This will include all methods up the prototype chains as well.) This is the default for ES5 compatibility, but it has the downside of stale references. For example, if you mix Foo
and Bar
to make FooBar
, then redefine a method on Foo
, FooBar
will not have the latest methods from Foo
. If this is not a concern for you, 'copy'
is the best value for this setting.'proxy'
- Uses an ES6 Proxy to "soft mix" prototypes. Unlike 'copy'
, updates to the base classes will be reflected in the mixed class, which may be desirable. The downside is that method access is not as performant, nor is it ES5 compatible.settings.staticsStrategy
'copy'
(default) - Simply copies all properties (minus prototype
) from the base classes/constructor functions onto the mixed class. Like settings.prototypeStrategy = 'copy'
, this strategy also suffers from stale references, but shouldn't be a concern if you don't redefine static methods after mixing.'proxy'
- Similar to settings.prototypeStrategy
, proxy's static method access to base classes. Has the same benefits/downsides.settings.initFunction
ts-mixer
will automatically call the function with this name upon constructionnull
(default) - disables the behaviorTanner Nielsen tannerntannern@gmail.com
FAQs
A very small TypeScript library that provides tolerable Mixin functionality.
The npm package ts-mixer receives a total of 476,569 weekly downloads. As such, ts-mixer popularity was classified as popular.
We found that ts-mixer demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Socket's package search now displays weekly downloads for npm packages, helping developers quickly assess popularity and make more informed decisions.
Security News
A Stanford study reveals 9.5% of engineers contribute almost nothing, costing tech $90B annually, with remote work fueling the rise of "ghost engineers."
Research
Security News
Socket’s threat research team has detected six malicious npm packages typosquatting popular libraries to insert SSH backdoors.