3

I'm a seasoned Java dev who needs to port a Java app for web use and I've been considering using Typescript to do this. For the time being, I'd like to keep the traditional Java style of packages being a hierarchy of folders and a single class per "leaf" file.

I've been looking at the Typescript docs and I see things like ../path/to/module. Are all includes relative like that? Is there some kind of base directory option where I can get something akin to import com.ancient.java.MyType;?

Also, is declaring a package com.ancient.java; something to be done in Typescript?

I've looked over the docs but I'm not finding them easy to read with all the talk about internal and external namespaces and exporting, etc.

Can someone boil this down to something that'll feel like Java for me to start out with? I'm sure I'll baby step into all the complex stuff later as needed. What does this look like in code?

Sam Washburn
  • 1,817
  • 3
  • 25
  • 43

1 Answers1

5

Organizing your typescript classes into 1-class per file and an organized folder hierarchy is perfectly acceptable and even encouraged in typescript.

If using typescript 2.0 or above your paths do not need to be relative. You can use the baseUrl: property to specify where non-relative (i.e. no . or ..) paths are rooted. For example of you had:

tsconfig.json 
src/
   foo/
       foo.ts
   bar/
       bar.ts

you could set "baseUrl": "./src" and then you could import 'foo/foo' and import 'bar/bar' without using relative path navigation.

I would discourage you from trying to declare packages/namespace/internal modules and the like in typescript. These types of things are mostly relics of the past, and not something I would venture to use in a new project.

What I would recommend is to stick to file-based modules, as this is the modern recommended approach for composing your application.

A file that has import or export statements is considered a "file module". Everything defined within it is private to the file and does not pollute the global namespace. Things that should be shared need to be exported and imported from other files.

For example you could write the MyType class in a file structure like this:

src/
    com/
        ancient/
            my-type.ts

my-type.ts Would look like:

export class MyType{
     constructor(){
        console.log('Hello World');
     }
}

and then you could import it in other files like:

import {MyType} from 'com/ancient/my-type'

You should not need to use the keywords namespace or module. These are mostly things that will only be found in type declaration files.

Daniel Tabuenca
  • 13,147
  • 3
  • 35
  • 38
  • A couple minor points. One, 'external modules' are exactly ES2015 modules and shouldn't be discouraged. Two, `declare module` is still frequently used in .d.ts files, not just legacy ones. – Paarth Oct 30 '16 at 07:34
  • You are correct, although they are no longer called "external modules". While officially they are just "module" I like to call them "file modules" to emphasize that the file itself is the module and not any use of `decalre module`. You are also right about potential use in modern declaration files. I was thinking about one particular use, and not others such as ability to re-open a module and augment it's types. I made the relevant edits to avoid any confusion. – Daniel Tabuenca Oct 30 '16 at 07:47