Typescript: Typescript should support --lib node

[nojvek]

Typescript already has settings to include lib.d.ts for es6, browser, dom e.t.c. Setting up typescript with node is really painful. It seems tutorials on the web are outdated. There is tsd , typings, and supposedly some integration with npm. What is the way to go? I spent a couple of days trying to get node and typescript to work and eventually just gave up and went with javascript.

I feel typescript is alienating a huge part of js node community by adding friction to get things working. It should't be this complicated.

There is already support for moduleResolution: node, adding support for node should be a parameter away in tsconfig.

I'd say when require('fs) or import fs from 'fs' fails, VSCode editor should offer an auto-fix suggestion.

[kitsonk]

You are raising multiple items here.

First, supporting node typings more "first class" will be occurring with TypeScript 2 and the @typings. Because type acquisition is hard, this is why the TypeScript team have been working to make it easier. TS2 needs to be released and the documentation, etc. will need to be flushed through.

It seems tutorials on the web are outdated.

That seems to be a wider community issue. While there is no plain Node.js tutorial on the official website, I am sure the TypeScript team would gladly accept a submission to the tutorials repo.

At the end of the day, TypeScript will be only one part of an larger ecosystem. As the design goals for TypeScript state it is a non-goal to:

4) Provide an end-to-end build pipeline. Instead, make the system extensible so that external tools can use the compiler for more complex build workflows.

Therefore, even when targeting a browser, TypeScript is part of a solution, but is seldom the full solution.

I'd say when require('fs) or import fs from 'fs' fails, VSCode editor should offer an auto-fix suggestion.

Like what? What helpful information could be provided? It is informing you already that it cannot find the module you are looking for.

I think you biggest "gripe" is that by default it isn't easy to switch from "assume a browser" to "assume a Node.js environment". Again that will be addressed in TS2... it should essentially be as simple as:

> tsc --init index.ts
> npm init
> npm install @typings/node --save

_Note, I haven't tried it yet and it is my limited understanding of how type acquisition is changing in TS2, as I can't remember if node_modules/@typings are auto-resolved in a project without further configuration._

[nojvek]

I agree with some of your points.

Basically typescript already understands browser types because it has a pre-set built of libs e.g.

 --lib                               Specify library files to be included in the compilation: 
                                       'es5' 'es6' 'es2015' 'es7' 'es2016' 'es2017' 'dom' 'webworker' 'scripthost' 'es2015.core' 'es2015.collection' 'es2015.generator' 'es2015.iterable' 'es2015.promise' 'es2015.proxy' 'es2015.reflect' 'es2015.symbol' 'es2015.symbol.wellknown' 'es2016.array.include' 'es2017.object' 

Having node as one of the libs makes sense since node is just another engine.

It also has

 --moduleResolution                  Specify module resolution strategy: 'node' (Node.js) or 'classic' (TypeScript pre-1.6).

Which means typescript is node aware at some level. It just doesn't know what node types are.

I am arguing that node is an equal host to the browser host therefore its definition should be included and should be a compiler flag away.

I should be able to take an existing node project and rename all js files to .ts, add --lib node and it should work. It shouldn't complain about core modules not being found.

[DanielRosenwasser]

Hey guys, I was actually pushing for a --lib node pretty recently. It very much does seem to be the ideal workflow for users in some sense.

However, after discussing it with @bowdenk7, we're a bit of the opinion that @types is better suited for this task. The rationale is that the Node API is not necessarily as stable as something like the API surface described in the ES spec, and so versioning matters a lot more. There are potential subtractive changes that we'd have to deal with which are breaking. Our lib.d.ts isn't versioned (which is a bad thing because people can't roll back temporarily to fix potential breaks), and I'm not so sure it would be a good thing to do the same to node.d.ts. Plus, setting node as a custom option for --lib seems to be about the same work as adding @types/node as a dependency and npm install-ing anyway.

All of that said, I would like to see if people hold the opinion that the convenience brought from this fix completely outweighs that problem. If that was the case, we could make our lib files available with TypeScript, but also make them available through @types in a versioned manner if people needed to roll back to something older. I do kind of like that idea personally.

[yortus]

My observations with using typescript@next for both browser and node.js projects:

Browser Project Setup

1. Done. Source files will have all browser APIs ambiently defined without any config needed.

Node.js Project Setup (with typescript@next):

1. npm install @types/node --save-dev to get node.d.ts from npm into the project
2. In tsconfig.json, add "lib": ["es2015"] to _opt out_ of having all the browser APIs ambiently defined
3. In tsconfig.json, add "types": ["node"] so tsc will look for node.d.ts (this _may_ be needed - see https://github.com/Microsoft/TypeScript/issues/9208#issuecomment-226711625)

So both sides have a point here. Changes with v2.0 do make it pretty easy to set up node.js projects. However, it isn't quite a level playing field, with browser projects still favoured out of the box.

[nojvek]

I'm fine with either typings or --lib as long as there is a consistent way
to get it for everything.

Back in the day when I used eclipse with java, it would be smart to
auto-fix my imports.

I'd really love to see the language service offer hints of fixing
automatically. It would really make the experience shine.

e.g

1) User types: import * as fs from 'fs'
2) There is a yellow squigly under fs. (yellow for autofixable error)
3) Hover says: Typings for node available [Install] [Cancel]

I'd say it would be sweet if I could just type away imports and it would
search for modules from npm and offer auto install hints

2nd example

1) import * as ws from 'ws'
2) Yellow squigly hint says: Typings and module available in npm
[Install][Cancel]

We live in an age of artificial intelligence. Its bizzare that I have to go
through so many hoops to get typescript and node working. Let's make our
experience painless.

On Friday, July 1, 2016, Daniel Rosenwasser [email protected]
wrote:

Hey guys, I was actually pushing for a --lib node pretty recently. It
very much _does_ seem to be the ideal workflow for users in some sense.

However, after discussing it with @bowdenk7 https://github.com/bowdenk7,
we're a bit of the opinion that @types is better suited for this task.
The rationale is that the Node API is not necessarily as stable as
something like the API surface described in the ES spec, and so versioning
matters a lot more. There are potential subtractive changes that we'd have
to deal with which are breaking. Our lib.d.ts isn't versioned (which is a
bad thing because people can't roll back temporarily to fix potential
breaks), and I'm not so sure it would be a good thing to do the same to
node.d.ts. Plus, setting node as a custom option for --lib seems to be
about the same work as adding @types/node as a dependency and npm install-ing
anyway.

All of that said, I would like to see if people hold the opinion that the
convenience brought from this fix completely outweighs that problem. If
that was the case, we could make our lib files available with TypeScript,
but also make them available through @types in a versioned manner if
people needed to roll back to something older. I do kind of like that idea
personally.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/TypeScript/issues/9466#issuecomment-230086346,
or mute the thread
https://github.com/notifications/unsubscribe/AA-JVIoeVZowohRpL2XpWEUjWjNiEXd_ks5qRgHwgaJpZM4JC2vT
.

[clavecoder]

The argument that TypeScript should treat NodeJS native modules like any other library is akin to AWB's tweet that NodeJS should not be considered a platform in the way that browsers are.

Whereas

• Angular 2 has made TypeScript so important to the JavaScript toolchain
• NodeJS is, indeed, a platform in the same way as the browser platform and the DOM
• because it is a platform, the developer experience for native NodeJS modules is different than other modules with respect to @types
• the rise of the browserfiy and webpack module loaders and Universal JavaScript have made require('module'), and by implication from 'module', central configuring library dependencies
• although external script bundlers permit you to declare var foo: any, import foo is mandatory for modern module-based toolchains
• TypeScript is greedy and does not allow you to import a non-TypeScript node module without turning off errors
• TypeScript has already made several concessions to the centrality of the NodeJS ecosystem

lib: ["node"] ought to become the way to import native NodeJS modules.

I would a agree that maintaining node.d.ts is larger than the TypeScript contributors. The team should, as the TC39 committee has done, solicit representation from the Node.js Foundation to help make lib: ['node'], lib: ['node4'], and lib: ['node6'] references to sanctioned node.d.ts files.

[basarat]

@DanielRosenwasser I understand the design to move this to @types. But I am team lib + node :). Its just tooooo common a use case :rose:

[nojvek]

I think typescript project should not maintain the lib files. Instead it
should dynamically pull them from as dependencies when installed "npm
install -g typescript".

That means as a user, typescript will work with browser and node out of the
box.

Making changes and maintaining the d.ts files can be done in their
respective repos.

On Wednesday, July 13, 2016, Kenneth Brubaker [email protected]
wrote:

@nojvek https://github.com/nojvek's reasoning echos AWB's tone-deaf
tweet that only the web matters. In the end they had to put a member of the
node team on the TC39 to work through the module loader debacle. If you
haven't noticed, look around, all the JS toolchains use, you guessed it,
NodeJS. Say, didn't TypeScript have to adopt the node module resolution
scheme? Why yes they did. Node's in your schema in a few different places.
It wont kill you to add it to lib. Take a cue from TC39 and get someone
from node to work with you. With the near release of Angular 2 and the
advent of Universal JavaScript both TypeScript and NodeJS are essential
assets of the JavaScript community. Please play together nicely.

I've just spent two days trying to get import * as assert from "assert"
to work--one `lib: ["es6", "node"] _should_ have fixed that. I shouldn't
have to go searching in GitHub repos to get it working.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/TypeScript/issues/9466#issuecomment-232550130,
or mute the thread
https://github.com/notifications/unsubscribe/AA-JVIosLzQQnOkA5QsAJjl14nEK1zWxks5qVbJTgaJpZM4JC2vT
.

[kitsonk]

@clavecoder I am tone deaf now?

You could have offered solutions to peoples problems, but no, you would rather complain that I am tone deaf. People do take some things personally.

[clavecoder]

@kitsonk, to me it would be an honor to be equated in any way with @allenwb, who has given so much to the software industry and to the JavaScript community in particular. You, @ahejlsberg, and the entire TypeScript team are similarly improving the lives of JavaScript coders in countless ways. So, no, you are not tone deaf. I attribute AWB's lack of seeing the importance of Node to the mind numbingly fast pace of change of the JavaScript developer experience. Likewise, whereas, TypeScript's original goals were to be a wrapper as thin as possible around JavaScript, it's rise to prominence as a fundamental tool of the development of, by far, the most popular JavaScript development framework, makes it hard not to consider it's role in the developer experience.

Bower's star has faded precisely because npm has become, again by far, the dominant library package management registry on the planet. This has made require('module') and, by implication, from 'module' essential ways to integrate JavaScript in larger projects. I've edited my comment to be more succinct; however, past TypeScript design decisions have demonstrated, in so many ways, that node is not just another library.

And I do most humbly thank you and the entire TypeScript team for their hard work and extraordinary contribution to the JavaScript community.

[kitsonk]

To avoid any confusion, I am just a member of the wider community, not part of the TypeScript team. I am the project lead for Dojo 2 which has a vested interest in the roadmap of TypeScript.

[clavecoder]

@DanielRosenwasser and TypeScript team, it looks as though the Node.js Foundation folks are interested in working with you: nodejs/LTS/issues/123. You may want to contact @rvagg, @nebrius, or @joshgav to see how they could work with you.

[clavecoder]

@nojvek, it, perhaps, should be an option of tsc --init where the developer could choose what platform they are targeting. Even if they are installing with npm, it lies with the developer to decide to use module loaders for bundling.

[nojvek]

Npm has a notion of peerDependencies.

I would expect typescript to have a default set of typings peerDependencies
for both browser and node.

This means, there are no extra steps to get node working. It works out of
the box. It's just npm "install -g typescript"

If a Dev wants to change versions of the libs, he just npm installs that
version or changes his package.json.

Typescript team also no longer has to worry about maintaining node.d.ts.
It's basically just adding a peerDependencies entry to its package.json.

I feel this is a clean solution and npm does most of the work.

Thoughts?

On Thursday, July 14, 2016, Kenneth Brubaker [email protected]
wrote:

@nojvek https://github.com/nojvek, it, perhaps, should be an option of tsc
--init where the developer could choose what platform they are targeting.
Even if they are installing with npm, it lies with the developer to decide
to use module loaders for bundling.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/TypeScript/issues/9466#issuecomment-232664516,
or mute the thread
https://github.com/notifications/unsubscribe/AA-JVDGc_YMLbMp09XhtsUdKpiUUDH0zks5qVjkQgaJpZM4JC2vT
.

[nebrius]

peerDependencies are deprecated and have been partially removed from npm 3, so that's a non-starter I'm afraid

[nojvek]

npm3 installs in a flat structure so just having dependencies should work
right?

On Thu, Jul 14, 2016 at 11:00 AM, Bryan Hughes [email protected]
wrote:

peerDependencies are deprecated and have been partially removed from npm
3, so that's a non-starter I'm afraid

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/TypeScript/issues/9466#issuecomment-232743183,
or mute the thread
https://github.com/notifications/unsubscribe/AA-JVIc3NdkgxJB_pdMAWzslqVSEbHcEks5qVnk6gaJpZM4JC2vT
.

[nebrius]

npm3 installs in a flat structure so just having dependencies should work
right?

It doesn't always install flat. If module a depends on version 1.0.0 of module c, but module b depends on version 2.0.0 of module c, then both versions of c are installed, with one of them thrown inside the node_modules folder of either a or b, as npm 2 does. This conflict is why peerDependencies are deprecated BTW, because they don't resolve this problem and break in unexpected/spectacular ways.

[kitsonk]

peerDependencies are deprecated and have been partially removed from npm 3, so that's a non-starter I'm afraid

peerDependencies is not deprecated. There was a change in behaviour in npm3 that did not auto-install those dependencies because it causes issues and conflicts. As far as I can tell this is a myth that has been perpetuated because of the change in behaviour. I would assume if it were actually deprecated, it would be noted in the documentation. The change in behaviour means that the developer has to deal with resolving conflicts by themselves, which is appropriate for peerDependencies and was the problem with it. I am unable to find one authoritative statement that it is deprecated.

It doesn't always install flat.

Correct. npm3 flattens by default, but has a fairly complex way of dealing with version conflicts. This is what happens when you build something that has unlimited, low cost access to the local filesystem, like Node.js does, not like how a browser does. This also leads to building a loader that doesn't allow remapping of packages, because again, relatively costless access to the local filesystem.

Of course, this was attempted to be solved by CommonJS and AMD being all part of a single loader specification back a decade ago with James Burke trying hard to get those of Node.js/CommonJS to have a single loader, but like all good points of hubris, people couldn't agree and so we ended up with CJS and AMD, only a decade later still find ourselves tripping over the same problems.

[kitsonk]

Typescript team also no longer has to worry about maintaining node.d.ts.

I really don't understand why you think this will magically happen. If the TypeScript team doesn't maintain them, then who does?

What version of Node.js should be installed? The version it is running under, is that the final target for the consumable code?

Should it be installed globally so that every project has the same typings?

How does the developer identify a project is for a browser or for node? What about if they are targeting Rhino, or Electron?

What about the @types with 2.0 do you not like? Pretty much everything you are talking about seems to be essentially that, though in a real maintainable way.

[nojvek]

Node.d.ts is currently maintained by a third party.

All I am saying is node is an environment equal to the browser.

When I install typescript. I expect it to understand my node code just the
way it understands my browser code. If it doesn't then I expect a
straightforward hint on how to fix it.

Google/Bing doesn't help because the way to install types is very
fragmented and confusing. A new user might be in for frustration.

On Thursday, July 14, 2016, Kitson Kelly [email protected] wrote:

Typescript team also no longer has to worry about maintaining node.d.ts.

I really don't understand why you think this will magically happen. If the
TypeScript team doesn't maintain them, then who does?

What version of Node.js should be installed? The version it is running
under, is that the final target for the consumable code?

Should it be installed globally so that every project has the same typings?

How does the developer identify a project is for a browser or for node?
What about if they are targeting Rhino, or Electron?

What about the @types
https://blogs.msdn.microsoft.com/typescript/2016/06/15/the-future-of-declaration-files/
with 2.0 do you not like? Pretty much everything you are talking about
seems to be essentially that, though in a real maintainable way.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/TypeScript/issues/9466#issuecomment-232865077,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-JVCO-ah-aaFsXI3lyNQztiOxnXHMhks5qVx7jgaJpZM4JC2vT
.

[kitsonk]

@nojvek to repeat myself, what about the @types with 2.0 do you not like?

[nojvek]

User scenario

Sample.js
Import * as fs from fs

User tries to compile sample.js. S?he gets the following error:

Compiler error:
Module fs not found. Learn how to install modules at
http://typescriptlang.com/help/modules?module=fs'?

Typescript help site maintains a list of most used modules. Since fs is
passed as parameter.

Typescript help site says:

1) Run: npm install @typings/node

2) Add typings to your tsconfig like this

3) add a /// reference typings/global/index.d.ts

My experience as a user is streamlined. Error messages offer contextual
help. I'm not battling old tutorials and Google.

On Friday, July 15, 2016, Kitson Kelly [email protected] wrote:

@nojvek https://github.com/nojvek to repeat myself, what about the
@types
https://blogs.msdn.microsoft.com/typescript/2016/06/15/the-future-of-declaration-files/
with 2.0 do you not like?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/TypeScript/issues/9466#issuecomment-232958253,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-JVI90UngiBp2m6dKiseqWX0EzV70-ks5qV5J4gaJpZM4JC2vT
.

[clavecoder]

@kitsonk @DanielRosenwasser what do you think about my list of reasons for using lib and the possibility of the Node Foundation helping to provide a sanctioned definition file (nodejs/lts#123)?

[nebrius]

peerDependencies is not deprecated. There was a change in behaviour in npm3 that did not auto-install those dependencies because it causes issues and conflicts. As far as I can tell this is a myth that has been perpetuated because of the change in behaviour. I would assume if it were actually deprecated, it would be noted in the documentation. The change in behaviour means that the developer has to deal with resolving conflicts by themselves, which is appropriate for peerDependencies and was the problem with it. I am unable to find one authoritative statement that it is deprecated.

I chatted with some npm friends and dug up the original thread on peerDependencies, and you're right, it's not technically deprecated. It very much is persona non grata though, and there is risk that they will be deprecated, as that is the direction the majority of people want to go in. As such, I still think it's not a very good choice, even if it's not officially deprecated (yet).

[DanielRosenwasser]

I definitely consider Node a platform, but platforms also often have a version associated with them. Node 10 might not have the same API surface as Node 0.10.33.

I think that a good design decision is better than a convenient-right-now one. Doing "the wrong thing" with declarations for Node.js could lead to a confusing user experience. Like I mentioned in the issue, I think we are very open to the idea of working with Node and the community to improve the workflow, so I'd like to have that discussion before committing to making this a --lib option.

[clavecoder]

Yup. Sanctioned libs are the best way to go. And while I said "lib": ["node"], obviously you would want node4, node6, etc. But I get your point that any update to node could affect the declaration file. On the other hand, it would be hard to get more complicated than the current es*** picture, and almost anything is better than the current state with nearly undiscoverable access to a community driven declaration file.

In the end, disoverablility of a unique procedure for @types/node is the current issue that, I think, needs to be addressed before 2.0 escapes beta. And by that I mean that you don't just add it to your node tutorial doc page, but you make it discoverable. One way could be an error message for unmatched imports of built-in node modules, say for import * as fs from 'fs', when moduleResolution is node.

[basarat]

If we force people down node v4 vs. node v6 lib etc, then that will increase the learning curve / decrease the usability of ts libs across node version :-/

[clavecoder]

@basarat, surely it would be nice if the version could be auto-discovered, and I suppose ...some-node-configuration... ['node'] could possibly default to the node environment being run in. But, regardless, a package author may want to target several versions with multiple compilation runs--angular 2 has separate builds for es5 and es2015, for example--so you can't automatically make versioning decisions go away. That's the thing about semantic versioning: it's always so confoundingly semantic. :-)

So, yeah, if the default node configuration could just work, that would be great, but the compiler would always have to allow for specified versions...just as it is doing with es* libs, frankly.

[nebrius]

If we force people down node v4 vs. node v6 lib etc, then that will increase the learning curve / decrease the usability of ts libs across node version :-/

To give an idea of the scope of changes, and to have specifics to discuss instead of generic concepts, the node5/6 breaking changes list gives a good idea. As you can see, there's a surprising amount of breaking changes there, the largest of which being the deprecation of the buffer constructor and the addition of a bunch of new buffer allocation methods that don't exist in 4.

I think auto discovery would be nice, as long as specifying specific versions is also easy. It's not uncommon for people to have one version installed locally and to deploy to a different version on the server (not that this is necessarily advisable, but it does happen).

[kitsonk]

I think auto discovery would be nice, as long as specifying specific versions is also easy. It's not uncommon for people to have one version installed locally and to deploy to a different version on the server (not that this is necessarily advisable, but it does happen).

I would say this happens quite regularly in corporate environments where the CI build pipeline will match production which is more slower to move to modern versions. So developers may very well be targeting something totally different than what is on their machine. Also there is a prevalence of n and nvm installed on development machines, which allows quick switching for such purposes.

[olalonde]

Any update on this? Wanted to try typescript in a Node.js environment but documentation is lacking

[mhegazy]

Any update on this? Wanted to try typescript in a Node.js environment but documentation is lacking

All you need to get started is the ts compiler and the node types. e.g.:

npm install typescript @types/node

node_modules\.bin\tsc a.ts --lib es6

https://github.com/Microsoft/TypeScript/issues/12964 tracks adding a tutorial.

[pleerock]

versioning applies to everything including es, dom, webworker. I don't know what is your strategy for dom, webworker and similar libs, how are you planning to control versioning when they will be changed? But I do know how you'll handle es. Its simply es5, then es6, then es7 etc. What if same strategy will be applied for node too? Like lib: ["node5"], node6, node7` etc ? I guess node follows semver and critical changes only between major versions?

Its just a suggestion, maybe you can came up with something better and more scalable for lib option for node and all other libs that may come in the future.

I think this is the case when not the best decision in terms of design should be chosen in favour of convenience and easy of use because of popularity of this issue and consumer mass that will need it.

[pocesar]

what is the correct target for node 7.6 for the native async / await support, but no import stuff?

[kitsonk]

It would be a npm install @types/node@^7.0.0 --save and tsc --lib es6.

[pocesar]

that generates _async helpers

[psulek]

For me, now that nodejs 7.7 has native async/await support, my tsconfig.json looks like this:

{
  "compileOnSave": false,
  "compilerOptions": {
    "outDir": "out",
    "target": "es2017",
    "module": "commonjs",
    "moduleResolution": "node",
    "sourceMap": true
  },
  "include": [
    "*.ts"
  ]
}

and generated JS does not have any _async helpers, just raw async and await keywords and it runs well.

[SimonMeskens]

Had to make a guide for someone, crossposting

Setting up TS for Node

tsconfig.json:

{
    "compilerOptions": {
        "module": "commonjs",
        "moduleResolution": "node",
        "target": **TARGET**,
        ...
    }
    ...
}

Install Node typings (change version to node environment):
npm install --save-dev @types/node@^8.0.0

What should TARGET be?

According to the compatibility chart:

Node 7: es2016
Node 8: es2016
Node 9: es2017
Node 10: es2018

[Bnaya]

@SimonMeskens there's no 100% compatible target. and nor would be. you can use babel preset env if you want to transpile the least possible by node version

[Bnaya]

I think typescript should include only ECMASCRIPT apis, and put the rest in DT.
Even DOM would have been better outside

[SimonMeskens]

What do you mean there's no 100% compatible target? Of course there isn't, not for browser, not for Node, not for anything else. I used the compatibility chart to figure out which targets were safe to use, just like I'd do in a browser. Target + target libs point at a spec and there is no 100% spec implementations. I also showed how to install @types/node, which is in charge of adding node-specific things (of which it seems to do a good job).

I disagree entirely with the OP here, I just thought I'd share my little guide to show you how to setup TS for node, since I know people are looking in this issue for solutions.

[Bnaya]

I appreciate your effort :)
I would add that, If one wants to transpile the minimum required, he needs typescript + babel with preset-env and the node target. (babel 7 can make it a bit easier, but some of ts features have issues there )

[SimonMeskens]

I don't think I've written a Node project yet that needs transpiling, since anything from es2016 onwards seems minor to me and Node 7 supports es2015 fully, but I'll keep it in mind.

[nevir]

and Node 7 supports es2015 fully

(except modules)

[SimonMeskens]

TypeScript supports modules natively, so TypeScript for Node 7 does support modules. Especially with the esModuleInterop flag.

[nicferrier]

@SimonMeskens thank you.

This issue was raised in 2016, it's 3 years later and still I think your post in this thread is the only thing I found on how to get typescript targetting node.

That is not very good.

I'll try and send a PR against the website to include your handy guide.

[SimonMeskens]

@nicferrier Please do!

[fiznool]

Sorry to hijack an old thread but this bit me today. Building a node app in TypeScript, buried in the codebase I had written prompt.detail instead of response.prompt.detail.

What should have happened? The TS compiler should have shown an error to indicate that prompt was not a variable.

What actually happened? Unbeknown to me, the default TS settings include lib.dom.d.ts which contains a definition of the browser prompt global function. TS therefore saw prompt and thought I was trying to use the aforementioned function.

Needless to say, a simple mechanism to pick the node libs only would have saved me pain here!

[pocesar]

@fiznool there's an issue for that, #18433 it happens a lot, but the timing has been missed for a breaking change