Recently, I've been following this new coding pattern:

// file class.ts
import { getValue, setValue } from "./methods";

class SuperClass {
    public getValue = getValue;
    public setValue = setValue;

    protected data = "some-data";
}

// file methods.ts
import { SuperClass } from "./class";

function getValue(this: SuperClass) {
    return this.data;
}

function setValue(this: SuperClass, value: string ) {
   this.data = value;
}

This approach allows us to separate our methods into a different file. However, there is now a circular dependency between class.ts and methods.ts. Despite how it may sound alarming, as long as the code execution remains non-circular, everything works smoothly. In this scenario, the methods.ts file does not execute any code from the class.ts. No problem!

You can also implement this pattern with a generic class like so:

class SuperClass<T> {
    public getValue = getValue;
    public setValue = setValue;

    protected data?: T;
}

function getValue<T>(this: SuperClass<T>) {
    return this.data;
}

function setValue<T>(this: SuperClass<T>, value: T) {
    this.data = value;
}

Here's a solution that I've used successfully with TypeScript version 2.2.2:

class MasterClass implements PartOne, PartTwo {
    // Only public members can be accessed in the class parts
    constructor(public message: string) { }

    // Assigning methods from prototypes to avoid accessibility issues
    methodOne = PartOne.prototype.methodOne;
    methodTwo = PartTwo.prototype.methodTwo;
}

class PartOne {
    methodOne(this: MasterClass) {
        return this.methodTwo();
    }
}

class PartTwo {
    methodTwo(this: MasterClass) {
        return this.message;
    }
}

When it comes to converting large, old JavaScript classes that utilize 'prototype' across multiple files into TypeScript, I opt for plain subclassing:

bigclassbase.ts:

class BigClassBase {
    methodOne() {
        return 1;
    }

}
export { BigClassBase }

bigclass.ts:

import { BigClassBase } from './bigclassbase'

class BigClass extends BigClassBase {
    methodTwo() {
        return 2;
    }
}

By doing this, you can import BigClass into any other TypeScript file.

Implementing modules allows for expanding a typescript class from another source file:

user.ts

export class User {
  name: string;
}

import './user-talk';

user-talk.ts

import { User } from './user';

class UserTalk {
  talk (this:User) {
    console.log(`${this.name} says relax`);
  }
}

User.prototype.sayHi = UserTalk.prototype.sayHi;

declare module './user' {
  interface User extends UserTalk { }
}

Example of how to use this implementation:

import { User } from './user';

const u = new User();
u.name = 'Frankie';
u.talk();
> Frankie says relax

If dealing with numerous methods, consider implementing the following approach:

// user.ts
export class User {
  static extend (cls:any) {
    for (const key of Object.getOwnPropertyNames(cls.prototype)) {
      if (key !== 'constructor') {
        this.prototype[key] = cls.prototype[key];
      }
    }
  }
  ...
}

// user-talk.ts
...
User.extend(UserTalk);

An alternative is to include the subclass in the prototype chain:

...
static extend (cls:any) {
  let prototype:any = this;
  while (true) {
    const next = prototype.prototype.__proto__;
    if (next === Object.prototype) break;
    prototype = next;
  }
  prototype.prototype.__proto__ = cls.prototype;
}

A revised iteration of the suggested design.

// modified.ts contents
import {fetchValue, setNewValue} from "./modified2";

export class LargeClass {
    // @ts-ignore - to bypass TS2564: Property 'fetchValue' has no initializer and is not definitely assigned in the constructor.
    public fetchValue:typeof fetchValue;

    // @ts-ignore - to bypass TS2564: Property 'setNewValue' has no initializer and is not definitely assigned in the constructor.
    public setNewValue:typeof setNewValue;
    protected data = "a-data";
}

LargeClass.prototype.fetchValue = fetchValue;
LargeClass.prototype.setNewValue = setNewValue;

//======================================================================
// modified2.ts contents
import { LargeClass } from "./modified";

export function fetchValue(this: LargeClass) {
    return this.data;
}

export function setNewValue(this: LargeClass, newData: string ) {
    this.data = newData;
}

Advantages

• No extra fields created in class instances resulting in minimal overhead: no additional memory consumption during construction or destruction. Type declarations are purely for TypeScript typings without impacting JavaScript runtime.
• Satisfactory IntelliSense functionality (validated on Webstorm)

Drawbacks

• Use of ts-ignore directive is necessary
• Syntax may appear less elegant compared to @Elmer's approach

The remaining characteristics of both solutions remain consistent.

If you want to organize your code into multiple files, you can implement multi file namespaces.

Create a file named Validation.ts with the following content:

namespace Validation {
    export interface StringValidator {
        isAcceptable(s: string): boolean;
    }
}

In another file named LettersOnlyValidator.ts (which uses the StringValidator from Validation.ts), add the following code:

/// <reference path="Validation.ts" /> 
namespace Validation {
    const lettersRegexp = /^[A-Za-z]+$/;
    export class LettersOnlyValidator implements StringValidator {
        isAcceptable(s: string) {
            return lettersRegexp.test(s);
        }
    }
}

Lastly, in the Test.ts file (which uses both StringValidator and LettersOnlyValidator from the previous files), include the following code:

/// <reference path="Validation.ts" />
/// <reference path="LettersOnlyValidator.ts" />

// Some samples to try
let strings = ["Hello", "101"];

// Validators to use
let validators: { [s: string]: Validation.StringValidator; } = {};
validators["Letters only"] = new Validation.LettersOnlyValidator();

Instead of creating a new function, why not utilize the built-in Function.call that JavaScript already provides.

class-a.ts

Class ClassA {
  bitten: false;

  constructor() {
    console.log("Bitten: ", this.bitten);
  }

  biteMe = () => biteMe.call(this);
}

In another file, bite-me.ts

export function biteMe(this: ClassA) {
  // do some stuff
  // here this refers to ClassA.prototype

  this.bitten = true;

  console.log("Bitten: ", this.bitten);
}

// Implementation

const state = new ClassA();
// Bitten: false

state.biteMe();
// Bitten: true

To learn more about how Function.call works, refer to the documentation on MDN.

Personally, I find the use of the @partial decorator to be a helpful way to simplify syntax and organize functionality within a single class by splitting it into multiple 🍬🍬🍬 class files. You can learn more about it here: https://github.com/mustafah/partials

// Here we have a declaration file for a BigClass with a method that takes a number and a string as arguments and returns a string

class BigClass {
  declare method: (n: number, s: string) => string;
}

// Now in the implementation file, we provide the actual implementation for the method
BigClass.prototype.method = function (this: BigClass, n: number, s: string) {
  return '';
}

One downside of this way of organizing code is that there is a risk of declaring a method without providing an actual implementation for it.

One way to incrementally enhance class methods is by utilizing both the prototype and Interface definitions:

import signIn from './signIn';
import browseStaff from './browse-staff';

interface EmployeeAPI {
  signIn(this: EmployeeAPI, data: SignInData): Promise<boolean>;
  browseStaff(this: EmployeeAPI): Promise<BrowseStaffResponse>;
}

class EmployeeAPI {
  // class implementation
}

EmployeeAPI.prototype.signIn = signIn;
EmployeeAPI.prototype.browseStaff = browseStaff;

export default EmployeeAPI;

Here is the method I have been using Check out the Mixins approach