We Keep Coding

Is adding a d.ts file to a JavaScript npm package a breaking change by SemVer rules?

If I had a purely JavaScript npm package with no dependence on TypeScript, and I wanted to add a d.ts type declaration file to it, along with a new "types" property in the package.json pointing to the file, would that be considered a breaking change? Would it necessitate a major version bump according to SemVer?
I could see either way, since it's not affecting the JavaScript at all, and it doesn't break the APIs of anything. However if someone is using the library in a TypeScript project and has made their own d.ts types for the library, it could conflict with those types, like with a "Duplicate Identifier" error.

SemVer states
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.
Adding a type declaration file is clearly no bug fix, so it is clearly not #3. The key here is, that if you add a type declaration file, all the code consuming the API will not break, because the actual js code will not change. Therefore there aren't any incompatible API changes which is another word for backwards compatibility.
This means, if you add a type declaration file, increase the minor version number.

Where does VSC get its information that's displayed in the tooltips?

When I hover over a method, VSC displays information on that method in a tooltip.
Example: Here, I hover over .on, a method I'm using from the Socket IO library. Then I can see documentation on .on:
Question: Where does VSC grab documentation from to display in the tooltips?
I couldn't find any of this info in the socket.io package, or any other respective package for different libraries.

That looks to come from #types/socket.io, which is part of DefinitelyTyped - the defacto repo for all TypeScript community-maintained type definitions.
VS Code provides IntelliSense for built-in symbols of browsers, Node.js, and virtually all other environments through the use of type definition .d.ts files. DefinitelyTyped is a repository of typings files for all major JavaScript libraries and environments. — vscode.readthedocs.io

Pretty sure it's from the docstring you can put inside at the top of a function

Go to Typescript Source Definition instead of Compiled Definition in Visual Studio Code

I am working on a typescript project with Visual Studio Code including multiple npm packages structured like this:
Source code: /src/index.ts
Compiled code: /dist/...
When I right click on imported objects and choose "Go to Definition" or click F12 or by clicking on the object with holding down CTRL, Visual Studio Code opens the corresponding .d.ts file in /dist
However, I want VSCode to open the corresponding .ts file in /src
Is it possible to change this behavior, as it is really annoying to manually search for the source file.
I've created git repo, so that you can try it yourself:
https://github.com/flolude/stackoverflow-typescript-go-to-definition
you just need to run yarn bootstrap in order to replicate the issue.

TypeScript 2.9 introduced a compilerOption called declarationMap. Per the release notes:
Enabling --declarationMap alongside --declaration causes the compiler
to emit .d.ts.map files alongside the output .d.ts files. Language
Services can also now understand these map files, and uses them to map
declaration-file based definition locations to their original source,
when available.
In other words, hitting go-to-definition on a declaration from a .d.ts
file generated with --declarationMap will take you to the source file
(.ts) location where that declaration was defined, and not to the
.d.ts.
I submitted a PR on your example repo to enable this setting.

The newer VSCode version (April 2022 or later) supports this with a feature called "Go to Source Definition" (see here). It is still a work in progress I believe (given this discussion thread), but should be working properly in most cases.

VSCode intelliSense autocomplete for javascript

I would like Visual Studio Code to autocomplete all words within the open document instead of the just the scope specific variables it finds. What should I change in the settings?
edit: code version 0.3.0 at time of question.

I just figured it out. This will use all words on the page for auto complete.
// Always include all words from the current document.
"javascript.suggest.alwaysAllWords": true,
// Complete functions with their parameter signature.
"javascript.suggest.completeFunctionCalls": true,

Even though it has been quite some time for this question, I thought I might be of help to anyone else who bumbles across the same question.
So here goes . And this is for the latest version of VS Code as of writing.
For a true intellisense, i.e. for example you intend to get all the methods related to "console" as soon as you press '.' , you can use the respective Typescript definition file.
Now I agree that this fix is targeted at node,and needs the same along with npm on your system. But still, works for all Major JavaScript work you might run across.
on Linux, for this, you'd need "npm" and install TypeScript Definition Manager (tsd) globally.
npm install -g tsd
then within your current project directory (or by changing to the project directory) , open a terminal window and add the following lines
tsd query node --action install
tsd query express --action install
then, as soon as you'll open your .js file in the current directory, you'll get proper autocomplete / intellisense for all DOM object and other possible stuff.
It worked for me, and this is the only reason I use VSCode on linux (for JavaScript at least, even though I like LightTable too)
for further information (and clarifications if I somehow couldnt manage to be clear enough) visit the following link:
Node.js applications on VS Code

Using Nodejs with Typescript

I would like to use Nodejs in my typescript project and downloaded node.d.ts from https://github.com/borisyankov/DefinitelyTyped/tree/master/node
But VisualStudio finds a lot of errors in the .d.ts file. They're all basically the same:
Error 2 exported interface 'Server' extends interface from private
module 'events' C:\Users\lhk\Desktop\typescript-game\strategy
go\node\node-0.8.d.ts 236 37 node-0.8.d.ts
All the error messages complain that a private interface is extended.
I searched SO and found this question:
nodejs require inside TypeScript file
One of the comments gives the advice to download node.d.ts from the Microsoft samples. I browsed the internet, found this article http://stackful.io/blog/typescript-nodejs-vim-and-linux-oh-my/ and downloaded the second version of node.d.ts , with the exact same result.
Where do I find a proper definitions file for nodejs and Typescript ?

For the 0.8.1-1 version of TypeScript, use the latest node.d.ts file from this github project:
https://github.com/soywiz/typescript-node-definitions
I was getting the same exported interface errors until I pulled the latest definition files from there.

I'm not entirely sure what the heck is going on here.
I suspect that the current version of the (0.8.1~1) node.js package for Typescript broke some stuff. I've been running into this too. I tweaked the node.d.ts file and marked a couple things "export" instead of "declare" and that got me past my compilation issues, but I'm finding that the functions are not showing up in the current scope.
FWIW, I have been playing around with a personal fork of typescript-require and typescript-wrapper (both of which required some tweaking to work with 0.8.1~1) and I'm wasn't too certain that everything is working as well as it should be, so I wasn't sure that the issue is my issue or something endemic to the current node/typescript.