Typescript: Support `register` to allow users to just require `.ts` files

[basarat]

Proposal

You simply do require('typescript').register() and then all require calls e.g. var foo = require('./foo') would load foo.ts if foo.js/json/etc are not found.

This would mean we would compile in-memory and completely skip all type checking and do a fast emit. This would however greatly help increase .ts adaption IMHO.

Currently there is a userland maintained : https://github.com/TypeStrong/ts-node

Motivation

CoffeeScript supports this via require('coffee-script').register(); (synonym for require('coffee-script/register');) so that once you call this function it patches require to support .coffee files.

E.g.

• Atom does this for coffee : here and here
• Grunt does this here

The implementation for coffeescript can be found here : http://coffeescript.org/documentation/docs/register.html

Where in typescript

This can potentially be done in an external NPM package, but:

• having it officially support would enhance adaption.
• give better statistics for typescript npm package as users would start requireing typescript (coffeescript downloads https://www.npmjs.com/package/coffee-script)

[billti]

I left a comment in the pull request also to this effect, but this functionality is deprecated in the Node API. Specifically, it states at https://nodejs.org/api/globals.html#globals_require_extensions

*Deprecated* In the past, this list has been used to load non-JavaScript modules into Node by compiling them on-demand. However, in practice, there are much better ways to do this, such as loading modules via some other Node program, or compiling them to JavaScript ahead of time.

While it does go on to say, Since the Module system is locked, this feature will probably never go away, it still seems undesirable to add new features the depend on deprecated features.

[mkusher]

@billti I can replace this register hook with bin ts-node(like babel-node), which will hook require and start application. And there'll be no way to "pollute" npm using this bin, what do you think?

[mhegazy]

We have been getting consistent feedback about this. i think we should reconsider the current position.

[basarat]

We have been getting consistent feedback about this. i think we should reconsider the current position.

FWIW @blakeembrey has done an excellent job : https://github.com/TypeStrong/ts-node :rose:

[blakeembrey]

Also just a note, but I don't recommend making it too easy to do this. It's good in specific contexts which should be heavily documented (yeah, guilty, missing in ts-node - I made assumptions on the context people would _try_ to use it), but you don't want to get into the situation like CoffeeScript where every CoffeeScript module was published as is on NPM and everyone used the register functionality which really brought down the quality in the node ecosystem (E.g. non-JS published on NPM won't work out of the box with package bundlers).

[igl]

Having it in a stand-alone module ala require('typescript/register') wouldn't clutter up lib/typescript.js with node specific code that is not used/would break in other envs.
Same reason why coffee and babel have it in seperate modules.

I like the idea of having a _fast_ compile-without-type-checks for hot module reloading.
Type-checking can be done in a slow threaded rebuild on the side.

[amcdnl]

@blakeembrey how many people are going to use a TS project that don't use TS though? I think you should start tspm ;)

[blakeembrey]

@amcdnl I think I missed some context, but you're joking about creating a TypeScript package manager so we can skip the JavaScript publishing? I think your first question is my point, most peoples main audience is still non-TS users. Anyway, not a fun idea - that'll take a long time to build, even though I got a bit of experience building typings now :wink:

[amcdnl]

@blakeembrey Yes, I was joking! I think it doesn't really matter whether ur a TS user or not, u want to take advantage of the rich JS community.

Side note: I was able to get this working w/ ts-node but breakpoints are never hit in my IDE ( VSCode ).

@basarat If this would "...greatly help increase .ts adaption IMHO", why is it not landing til 2.0? That seems pretty far out ATM.

[felixfbecker]

The only reason I want this is so I can do gulp --require "typescript/register" and name my gulpfile gulpfile.ts

[blakeembrey]

@felixfbecker FWIW, you can already write gulpfile.ts without a require - just install ts-node as a dependency and it'll work.

[outring]

As @billti mentioned, API for module registration is deprecated, so as a workaround could be used the explicit entry point execution:

require('typescript').execute('./index.ts');

Everything required inside of index.ts and it's dependencies would be loaded using TS-enabled require()

[felixfbecker]

@blakeembrey It worked indeed, but how? Does gulp magically detect an installation of ts-node? Will it work for others like mocha too?

[outring]

@felixfbecker gulp (as well as mocha and others) just do require("whateveryouwant") which registers module loader for some file extension, see https://nodejs.org/api/globals.html#globals_require_extensions

[blakeembrey]

@felixfbecker It works by using https://www.npmjs.com/package/rechoir, which is mapping .ts and .tsx to ts-node already. It won't work for Mocha and some other CLIs, but to make it work is usually straightforward - for Mocha, they have a compiler option in the CLI.

[isiahmeadows]

BTW, even though it's deprecated, I don't think they're particularly inclined to remove it ATM because it'll break the entire Node ecosystem (we don't have an ES6 loader yet).

[ghost]

One major problem I have is being unable to specify a tsconfig. In my use-case, I'm trying to compose a gulpfile.ts (which gulp uses ts-node to interpret), to compile ts files meant to be consumed from a browser. The problem is that gulp runs on node, which is a different platform than the target platform for the rest of my app. My tsconfig.json is set up with settings for browser compilation, which don't make sense for gulp to try to use.

Proposed solution: allow the config object to be injected (it may itself be required from a json file), e.g.
require('typescript').register( config )

[blakeembrey]

@errorx666 please submit an issue on ts-node, it's unlikely someone here will be able to help you. However, I'm not sure that the proposal would work - how would one require('typescript').register() before gulp, etc? This is actually a known issue though, so feel free to look over in ts-node.

Edit: For reference, your suggestion exists in ts-node: https://github.com/TypeStrong/ts-node#programmatic-usage.

[taxilian]

I haven't gotten around to releasing it, but I modified the typescript-require package to basically do this for us; it actually does output javascript (to a specified temp directory) and if used the way we recommend it uses the tsconfig.json file, but it acts as though it were loading the .ts files directly.

It works generally very seemlessly; if there was interest I'd be happy to contribute it in whatever way was convenient as an alternative to ts-node. It does require that you start with a javascript file and then just allows you to require typescript files... the full project is built when the first file is required (I find that doing in-memory compilation without outputting files doesn't work well for larger projects).

If anyone is interested, you can find it here: https://github.com/gradecam/typescript-require

[isiahmeadows]

@taxilian I might file an issue against ts-node for this, since that may help drastically reduce startup costs. Also, if you haven't already, see about routing the source map to a separate temporary file as well, so that doesn't wind up in memory for the compiled source, since Node keeps the JS source in memory for Function.prototype.toString (the wrapper is technically a function closure) and error reporting, albeit compressed IIRC. Source map reporting also involves reading the original source, which is also kept in memory in case the underlying file changes.

FWIW, Babel already does some caching, and it might be a good idea for TypeScript to do the same.

[listepo]

Hi, any news?

[mhegazy]

have you tried [ts-node] (https://www.npmjs.com/package/ts-node)?

[trusktr]

have you tried [ts-node] (https://www.npmjs.com/package/ts-node)?

~How do you use it in the same form at babel register?~

Nvm, I see the register method.

[wavded]

This would be handy as it would interoperate with a common pattern in CLI tools (tape comes to mind) as well as node itself (without a need for ts-node).

[Qix-]

Not having the ability to pass --register typescript/register to my testing tools is a real PITA. Please stop trying to be smarter than your users - we have legitimate reasons for asking for these things.