How to structure utility class

I have several utility functions. What is the best way to package these up, and then import them?

This is what I am trying to do:

import * as util from './util'

export class myClass{
     constructor()
     {
           util.doSomething("test");
     }
}

Then in the class:

export class Util{
    doSomething(val: string){ return val;}

    doSomethingElse(val: string{ return val;}
}

The error message I get from VS is:

Property doSomething does not exist on type util.

If you create a file utils.ts which contains

export default class Utils {
    static doSomething(val: string) { return val; }
    static doSomethingElse(val: string) { return val; }
}

then you can simplify your client code like this:

import Utils from './utils'

export class MyClass {
     constructor()
     {
         Utils.doSomething("test");
     }
}

There's a couple problems here:

1. You're not instantiating anything, and doSomething is an instance method
2. When you do import * as util, util represents the module, not an object in it.

If you want Util, you should just import that:

import { Util } from './util'

Next, you should instantiate Util, before finally calling the method on it:

var u = new Util();
u.doSomething("test");

Here's your code patched up:

import { Util } from './util'

export class MyClass{
     constructor()
     {
         var u = new Util();
         u.doSomething("test");
     }
}

All that said, there seems to be something odd about the way you're using your utils. This is totally personal opinion, but I wouldn't invoke methods that "do something", i.e. cause side effects, in a constructor.

Also, the methods in Util don't really look like they need to be in that class, since the class holds no state that they depend on. You can always export regular functions from a module. If you wrote your utils module like this:

export function doSomething(val: string) { return val; }

export function doSomethingElse(val: string) { return val; }

you'd be exporting your functions directly and would sidestep the instantiation hassle, and in fact your original code would work correctly as is.