Comment by danenania | Hacker News Reader

Comment by danenania | Hacker News Reader

Parent Full thread

We're working on converting EnvKey’s[1] babel/ES6 codebase to TypeScript. It has been a true pleasure so far and has already brought gains in safety and productivity. I've never worked with a type system that is so intuitive and so rarely violates the principle of least surprise. It's amazingly easy to pick up, and also easy to gradually introduce it to existing js code in an iterative fashion. Color me impressed!

A few questions for TS veterans:

- With babel, we used the module-resolver plugin to set a custom root for absolute imports. In TS, it seems relative imports (import x from '../../../i-hate-life') are the norm, which turns ugly fast. How are folks dealing with this? Or aren’t they?

- Our codebase uses Ramda heavily for FP, and it can be hard to get TS to play nicely sometimes. Any tips on how to most effectively do Ramda/FP in TS?

- Am I missing out by not switching to VSCode? I’m using ST3 currently and it works, but there’s no fancy intellisense. Are the benefits worth picking up a new editor for?

1 - https://www.envkey.com

> Am I missing out by not switching to VSCode? I’m using ST3 currently and it works, but there’s no fancy intellisense. Are the benefits worth picking up a new editor for?

Well... typescript comes with tsserver, which is a local language-server (a Typescript LSP-server), which is what VSCode uses to provide all that goodness.

If you find a LSP-plugin for your favorite editor, it should thereotically be able to offer the same.

For instance, Emacs has tide[1] which uses tsserver (just like VSCode) to provide the same functionality.

I’d be surprised if there were no LSP or tsserver-clients for ST3. No need to leave something you know well over a single feature it may actually support.

[1] https://github.com/ananthakumaran/tide

About module resolution, you are looking for "paths" compiler option :

https://www.typescriptlang.org/docs/handbook/module-resoluti...

The "paths" compiler option only instructs TypeScript where to find files for resolution, but doesn't automatically rewrite those path aliases to their correct locations after build. There are plugins for JS bundlers like Webpack and Rollup so that they too can understand the path aliases, but if you're just looking to run the build JavaScript with vanilla Node, I've found the following two projects useful:

- https://github.com/dividab/tsconfig-paths - resolves paths aliases at runtime in Node

- https://github.com/duffman/tspath - run after build, it rewrites the imports in the resulting JavaScript files

I've switched to VSCode after years of WebStorm, almost painlessly. I would advise to try it for 2/3 weeks (taking the time to configure it and install relevant plugins as you go), that should be enough to give you a sense of it's working you or not

Do you feel you miss anything from WebStorm?

The new Tuple improvements in Typescript 3 should help give Ramda the chance at much better type improvements soon, if a smart developer takes a crack at updating the definitions for it.

The tuple improvements should be quite exciting for many FP/FP-ish libraries in TS.

The best option right now for keeping relative imports clean is using the `paths` compiler option to create aliases. This works most of the time but in some cases typescript won't rewrite paths in the javascript output so modules can't be resolved at runtime, so you'll need to use webpack or another tool in your build script to rewrite them.

See: https://decembersoft.com/posts/say-goodbye-to-relative-paths...

If you're using webpack with ts-loader you can use https://www.npmjs.com/package/tsconfig-paths-webpack-plugin to create aliases in webpack. awesome-typescript-loader has the same functionality available too I believe

Cool, that looks like it could work for client-side code that gets run through webpack, but what about for a node-friendly library?

I use tsconfig's `paths` in combination with the `require-rewrite` npm module (https://github.com/IUnknown68/require-rewrite).

Here's an example:

    // tsconfig.json
    ...
    "paths": {
        "#src/*": ["src/*"],
    }
    ...

    // package.json
    ...
    "requireRewrite": {
        "map": [
             [
                "#src/",
                "dist/src/"
             ],
        ]
    }
    ...
   
    // src/path1/x.ts
    import { X } from '#src/path2/y.ts`

> Am I missing out by not switching to VSCode?

I would say yes! VSCode also has many other things to offer over ST3 besides IntelliSense btw.

Yeah? Would you mind giving a quick overview?

The biggest three advantages I can think of right now:

* Git integration: You can directly edit in diffs, commit from the sidebar, see your submodules and commit in them, ...

* Integrated terminal which can also run tasks, so colors and input will work

* Much better debugging support (AFAIK ST3 has none out-of-the-box)

It's been a while since I've seriously used Sublime Text though.

Also framework plugins that leverage all of that, Vetur is a work of art.

Cool, thanks! I think I'll give it a shot.

I’ve reluctantly switched from st3 to vscode for all of my TS projects. the auto import feature makes dependency management... manageable (so may solve 1. for you too). i think the slightly slower UI is more than made up for with all kinds if nice autocompletes and powerful rename/refactoring capabilities.

for a functional library that plays nicely with TS check this out: https://github.com/gcanti/fp-ts

Looks interesting, but I get the feeling I need to have already downed a few gallons of Haskell kool-aid to understand this? Is there a beginner-friendly overview somewhere?

What's nice about Ramda is that while it uses the Haskell-ish vocabulary and type signatures in its docs, someone can also just dive in and start using it as if it were an underscore-like library and not worry about all the more cerebral stuff.

Reply on news.ycombinator.com