[node] Adds a 'typesVersions' entry so that Node definitions can start leveraging new compiler features.

[rbuckton]

Please fill in this template.

• Use a meaningful title for the pull request. Include the name of the package modified.
• Test the change in your own code. (Compile and run.)
• Add or edit tests to reflect the change. (Run with npm test.)
• Follow the advice from the readme.
• Avoid common mistakes.
• Run npm run lint package-name (or tsc if no tslint.json is present).

[typescript-bot]

@rbuckton Thank you for submitting this PR!

Because this is a new definition, a DefinitelyTyped maintainer will be reviewing this PR in the next few days once the Travis CI build passes.

In the meantime, if the build fails or a merge conflict occurs, I'll let you know. Have a nice day!

[typescript-bot]

@rbuckton The Travis CI build failed! Please review the logs for more information.

Once you've pushed the fixes, the build will automatically re-run. Thanks!

[rbuckton]

Looks like the jsforce definitions have types that incorrectly specify that they implement Promise, however this is not actually the case. Changed these definitions to use PromiseLike instead.

[typescript-bot]

After 5 days, no one has reviewed the PR 😞. A maintainer will be reviewing the PR in the next few days and will either merge it or request revisions. Thank you for your patience!

[Flarna]

Honestly speaking I'm not a fan of duplicating node definitions. Isn't it possible to move the common part (I expect this is >95%) into one file and include it by the 2.1 and 3.1 version?

[rbuckton]

In the long term, yes. While this is supported by the "typesVersions" feature, I discovered an issue with dtslint that needs to be addressed first, as it currently disallows using .. from within the ts3.1 folder.

[Flarna]

Would it work to put the common part in ts3.1 folder until dtslint is fixed?

[rbuckton]

Possibly, but if I can I will try to narrow down the dtslint issues in the next few days and possibly revise this PR.

[rbuckton]

The bug is actually in types-publisher. I have a PR up to address it: microsoft/types-publisher#520

[Flarna]

create a common file to be included in 2.1 and 3.1 variants to avoid duplication.

[Flarna]

@rbuckton I requested changes to this PR as discussed above. I have seen that your dtslint fix has been merged therefore I expect this should not land as it is.

[Flarna]

The tests are still duplicated, lso tslint and quite some part of the typescript config but for these two it's not that critical.
I think the repo Readme should also include a guideline for this approach.
It would be also cool if there is some tool to verify that both definitions "match" to avoid that they get async.

[Flarna]

@microsoft @DefinitelyTyped @jkomyno @a-tarasyuk @alvis @r3nya @BrunoScheufler @smac89 @tellnes @DeividasBakanas @eyqs @Hannes-Magnusson-CK @KSXGitHub @hoo29 @kjin @ajafff @islishude @mwiktorczyk @matthieusieben @mohsen1 @n-e @octo-sniffle @parambirs @eps1lon @SimonSchick @ThomasdenH @WilcoBakker @wwwy3y3 @ZaneHannanAU @jeremiergz @samuela

fyi, please take a look also

[rbuckton]

I removed the duplication in ts3.1/node-tests.ts and verified that tests are still run for ts3.1 when using the relative import.

[typescript-bot]

@rbuckton The Travis CI build failed! Please review the logs for more information.

Once you've pushed the fixes, the build will automatically re-run. Thanks!

[Flarna]

Looks fine from my point of view. Would be nice if others working on node typings add also there votes.

[SimonSchick]

Can we make this 3.2 so we can use bigint?

[KonanMentor]

I have a little concern regarding the file structure: common.d.ts and index.d.ts approach.

We'll have to modify common.d.ts each time another module gets improved typings. These changes
a) hard to review
b) potential place for mistakes during copy-paste

Basically, for changes like #27346 we'll have to do the following:

1. Move a module from common.d.ts to index.d.ts
2. Put updated module to ts3.n/index.d.ts
3. Somehow provision the module for all previous ts.3(n-1), ts.3(n-2), ... typings (it's gone from common.d.ts)

I suggest to split common.d.ts into multiple files (one file per module) beforehand. So the file structure will look like

├── ...
├── http.d.ts
├── fs.d.ts
├── stream.d.ts
├── index.d.ts
├── ts3.1
│   ├── fs.d.ts
│   ├── index.d.ts
│   └── stream.d.ts
└── ts3.2
    ├── fs.d.ts
    └── index.d.ts

Here fs and stream modules were changed for ts3.1 and only fs module was changed for ts3.2.

ts3.2/index.d.ts may look like

/// <reference path="../ts3.1/stream.d.ts" />
/// <reference path="../http.d.ts" />
/// <reference path="../..." />
...

---

In most cases we would like to reuse modules from the previous ts typings version. So maybe it even makes sense to create "symlink" for each module of ts3.n folder.

It will help to avoid confusion referencing different typescript versions (ts3.1 and ts2.1 in the example above).

Also it should be useful when e.g. ts3.1/http.d.ts has some useful changes that we expect to have in ts3.2. To propagate these changes to ts3.2 we should not forget to change ts3.2/index.d.ts to point to ../ts3.1/http.d.ts instead of ../http.d.ts.

So "symlink" version of ts3.2/index.d.ts may look like

/// <reference path="../ts3.1/stream.d.ts" />
/// <reference path="../ts3.1/http.d.ts" />
/// <reference path="../ts3.1/..." />
...

Where ts3.1/http.d.ts may contain

/// <reference path="../http.d.ts" />

simply referencing the same module of the previous ts version if no changes are required for this module in this particular ts version.

@rbuckton, @Flarna, others, what do you think about it?

[Flarna]

@KonanMentor I think splitting the files is a good idea, independent of this change.

As long as old typescript versions shall be supported by node type definitions I would avoid to use new features where possible. In the end we have to find a 2.1 variant for anything and as a result both variants needs to be maintained.

[rbuckton]

@Flarna, @KonanMentor: Given that this PR has become stale and splitting out node is a fairly large change on its own, I've created #32567 to address the split on its own (without "typesVersions" support).

[rbuckton]

Closing in favor of #32691.