Clone https://github.com/DefinitelyTyped/DefinitelyTyped, cd into it and npm i, then:

$ npm i @definitelytyped/[email protected] && npm test through
...

> [email protected] test
> dtslint types "through"

$ npm i @definitelytyped/[email protected] && npm test through
...

> [email protected] test
> dtslint types "through"

Error: ENOENT: no such file or directory, open '../notNeededPackages.json'

I haven't tried to dig into why. It might be that I'm not understanding something, but I think I'm following the docs at https://github.com/DefinitelyTyped/DefinitelyTyped#running-tests.

DefinitelyTyped/DefinitelyTyped#45845 should have failed when it tested pouchdb-core (and its dependents), but it didn't even test those.

The dependency chain is pouchdb-core -> node-fetch -> node. All references are triple-slash references.

To repro this, make a change in node. Then check whether the "Testing NNN dependent packages:" line includes pouchdb-core.

Expected: It does.
Actual: It doesn't.

I could not install dependencies, because of gfw, we chinese could not access raw.githubusercontent.com now.

[1/5] Validating package.json...
[2/5] Resolving packages...
error An unexpected error occurred: "https://raw.githubusercontent.com/Microsoft/types-publisher/fc21ead08a786201e1874c1f4b61308f1bbdbdf2/package.json: connect ECONNREFUSED 151.101.228.133:443".

Let's take a big PR like "add Node 16" - today it's tested via the .d.ts files and humans look over and guestimate whether this is going to break projects.

We could support: "@typescript-bot pack this" which would trigger a HTTP call to the publisher bot, instead of running main() it would:

• change definitelyTypedZipUrl to be the zip for the PR ( e.g. https://codeload.github.com/DefinitelyTyped/DefinitelyTyped/tar.gz/pull/52357/head )
• take the packages to deploy from the bot request
• deploy the version as a different npm tag, and not as 'latest' so people don't get it by default

Happy to pair on this if folks are interested

See DefinitelyTyped/DefinitelyTyped#38624 (comment)

Given some @types package P that depends on another @types package Q,
P's dependencies are implicitly published as

"dependencies": {
  "@types/q": "*"
}

Assume there is an update Q' and an update P' that depends on Q'.

Consumers of P who update to P' do not get Q' installed, because the old version of Q in the consumer's lockfile satisfies the dependency of "*". This leaves consumers of P to either manually edit their lockfile or explicitly depend on Q' in their application, both of which are not ideal solutions.

Definitely Typed should implicitly add the newest version of other DT packages to the published package.json.

Related: microsoft/types-publisher#11 microsoft/types-publisher#12 microsoft/types-publisher#360

See DefinitelyTyped/DefinitelyTyped#42271; the author had to add a bunch of d.ts files to OTHER_FILES despite the test referencing them.

eg https://github.com/DefinitelyTyped/DefinitelyTyped/pull/42271/files#diff-48021d025579ebbb776fa85fbb6a8b80R2

Sometimes it appears that Definitely Typed fails to clone, but the clone never times out, and the publisher is stuck waiting forever.

Instead, the clone should wait no more than one or two thousand seconds before timing out and killing the process (or waiting until next time).

See build https://dev.azure.com/definitelytyped/DefinitelyTyped/_build/results?buildId=24313
I've ran into the same issue on MacOS so this is not isolated and occurs very frequently.

I was able to to reduce the frequency drastically by reducing the parallelism in https://github.com/microsoft/types-publisher/blob/e3ccf31258ae76af4dffbbe44297af2c435f7dd7/src/tester/test-runner.ts#L144

eg. Math.floor(nProcesses / 4).

This didn't really affect testing speed.

I realise this is an npm issue but maybe some steps should be taken to ensure smooth sailing for us in the meantime.

Suggested solutions:

• Reduce parallelism, should probably restrict to 4 threads max.
• Add retry to handle this specific error.

I could be wrong, but it seems one cannot remove old version of the DT anymore.
In the case of DefinitelyTyped/DefinitelyTyped#47781 v4 of the package is to be removed (3 years old, just burden on CI) but it cannot get pass the check:
https://github.com/DefinitelyTyped/DefinitelyTyped/pull/47781/checks?check_run_id=1137596113
If I understand correctly, the version check picks v4 from the diff (but this is to be removed) and tries to match that version in the versions of current packages (current => 9 and 8):

// part of parsed packages information
versions: [
    Semver { major: 9, minor: 0, patch: 0 },
    Semver { major: 8, minor: 1, patch: 0 }
  ],

// part of affected versions information
[
  { name: 'fs-extra', version: '*' },
  { name: 'fs-extra', version: { major: 4, minor: undefined } }
]

as the version 4 is missing, the CI fails the check.
https://github.com/DefinitelyTyped/DefinitelyTyped/pull/47781/checks?check_run_id=1137596113#step:5:27

If you edit only notNeededPackages.json to add one entry, but don't delete anything from the filesystem, CI passes when it should actually fail. Entries in notNeededPackages.json imply that their associated types on DT have been deleted.

I suspect throttling or just performance hiccups on github's end. There's no retry logic in the multiple calls.

A run looks like this. Notice that is-number-like, redux-router and quick-hash work fine, but turbostatus and vigour-ua don't log after "Requesting from github".

Publishing is-number-like...
Tag @types/[email protected] as ["ts2.0","ts2.1","ts2.2","ts2.3","ts2.4","ts2.5","ts2.6","ts2.7","ts2.8","ts2.9","ts3.0","ts3.1","ts3.2","ts3.3","ts3.4","ts3.5","latest"]
Requesting from github: repos/DefinitelyTyped/DefinitelyTyped/commits?path=types%2fis-number-like
Found related commits; hash: b1ca3864162b5f3ea4625a75f7798368b4d269a4
Requesting from github: search/issues?q=is:pr%20is:merged%20b1ca3864162b5f3ea4625a75f7798368b4d269a4
Latest PR: 35629
Requesting from github: repos/DefinitelyTyped/DefinitelyTyped/pulls/35629
Current date is Wed May 22 2019 16:14:39 GMT+0000 (Coordinated Universal Time)
  Merge date is Wed May 22 2019 16:07:09 GMT+0000 (Coordinated Universal Time)
I just published [`@types/[email protected]` to npm](https://www.npmjs.com/package/@types/is-number-like).
Posting to github at repos/DefinitelyTyped/DefinitelyTyped/issues/35629/comments: {"body":"I just published [`@types/[email protected]` to npm](https://www.npmjs.com/package/@types/is-number-like)."}
From github: {"url":"https://api.github.com/repos/DefinitelyTyped/DefinitelyTyped/issues/comments/494871485","html_url":"https://github.com/DefinitelyTyped/DefinitelyTyped/pull/35629#issuecomment-494871485","issue
Done logging latency
Publishing quick-hash...
Tag @types/[email protected] as ["ts2.0","ts2.1","ts2.2","ts2.3","ts2.4","ts2.5","ts2.6","ts2.7","ts2.8","ts2.9","ts3.0","ts3.1","ts3.2","ts3.3","ts3.4","ts3.5","latest"]
Requesting from github: repos/DefinitelyTyped/DefinitelyTyped/commits?path=types%2fquick-hash
Found related commits; hash: b1ca3864162b5f3ea4625a75f7798368b4d269a4
Requesting from github: search/issues?q=is:pr%20is:merged%20b1ca3864162b5f3ea4625a75f7798368b4d269a4
Latest PR: 35629
Requesting from github: repos/DefinitelyTyped/DefinitelyTyped/pulls/35629
Current date is Wed May 22 2019 16:15:00 GMT+0000 (Coordinated Universal Time)
  Merge date is Wed May 22 2019 16:07:09 GMT+0000 (Coordinated Universal Time)
I just published [`@types/[email protected]` to npm](https://www.npmjs.com/package/@types/quick-hash).
Posting to github at repos/DefinitelyTyped/DefinitelyTyped/issues/35629/comments: {"body":"I just published [`@types/[email protected]` to npm](https://www.npmjs.com/package/@types/quick-hash)."}
From github: {"url":"https://api.github.com/repos/DefinitelyTyped/DefinitelyTyped/issues/comments/494871632","html_url":"https://github.com/DefinitelyTyped/DefinitelyTyped/pull/35629#issuecomment-494871632","issue
Done logging latency
Publishing redux-first-router...
Tag @types/[email protected] as ["ts2.4","ts2.5","ts2.6","ts2.7","ts2.8","ts2.9","ts3.0","ts3.1","ts3.2","ts3.3","ts3.4","ts3.5","latest"]
Requesting from github: repos/DefinitelyTyped/DefinitelyTyped/commits?path=types%2fredux-first-router
Found related commits; hash: 083ba71eab7e16270bcb124954370f08f84f8b33
Requesting from github: search/issues?q=is:pr%20is:merged%20083ba71eab7e16270bcb124954370f08f84f8b33
Latest PR: 35500
Requesting from github: repos/DefinitelyTyped/DefinitelyTyped/pulls/35500
Current date is Wed May 22 2019 16:15:25 GMT+0000 (Coordinated Universal Time)
  Merge date is Wed May 22 2019 16:11:27 GMT+0000 (Coordinated Universal Time)
I just published [`@types/[email protected]` to npm](https://www.npmjs.com/package/@types/redux-first-router).
Posting to github at repos/DefinitelyTyped/DefinitelyTyped/issues/35500/comments: {"body":"I just published [`@types/[email protected]` to npm](https://www.npmjs.com/package/@types/redux-first-router)."}
From github: {"url":"https://api.github.com/repos/DefinitelyTyped/DefinitelyTyped/issues/comments/494871788","html_url":"https://github.com/DefinitelyTyped/DefinitelyTyped/pull/35500#issuecomment-494871788","issue
Done logging latency
Publishing turbostatus...
Tag @types/[email protected] as ["ts2.0","ts2.1","ts2.2","ts2.3","ts2.4","ts2.5","ts2.6","ts2.7","ts2.8","ts2.9","ts3.0","ts3.1","ts3.2","ts3.3","ts3.4","ts3.5","latest"]
Requesting from github: repos/DefinitelyTyped/DefinitelyTyped/commits?path=types%2fturbostatus
Publishing vigour-ua...
Tag @types/[email protected] as ["ts2.2","ts2.3","ts2.4","ts2.5","ts2.6","ts2.7","ts2.8","ts2.9","ts3.0","ts3.1","ts3.2","ts3.3","ts3.4","ts3.5","latest"]
Requesting from github: repos/DefinitelyTyped/DefinitelyTyped/commits?path=types%2fvigour-ua
Checking for cache file at D:\home\site\wwwroot\bin\lib/../../cache/npmInfo.json...
Reading cache file...
Done!

https://www.npmjs.com/package/@types/react-dom contains 18.0.2 but the latest distribution tag still points to 18.0.0 even though 18.0.2 was published after 18.0.0.

$ npm dist-tag @types/react-dom
latest: 18.0.0
ts2.0: 0.14.20
ts2.1: 15.5.0
ts2.2: 15.5.0
ts2.3: 16.0.3
ts2.4: 16.0.3
ts2.5: 16.0.3
ts2.6: 16.0.6
ts2.7: 16.0.6
ts2.8: 16.9.7
ts2.9: 16.9.8
ts3.0: 16.9.8
ts3.1: 16.9.8
ts3.2: 16.9.9
ts3.3: 17.0.0
ts3.4: 17.0.1
ts3.5: 17.0.5
ts3.6: 17.0.9
ts3.7: 17.0.11
ts3.8: 17.0.11
ts3.9: 18.0.2
ts4.0: 18.0.2
ts4.1: 18.0.2
ts4.2: 18.0.2
ts4.3: 18.0.2
ts4.4: 18.0.2
ts4.5: 18.0.2
ts4.6: 18.0.2
ts4.7: 18.0.2

Original report: DefinitelyTyped/DefinitelyTyped#59748 (comment)

The DefinitelyTyped license file states that

Copyrights are respective of each contributor listed at the beginning of each definition file.

—however, the license file that is used when publishing packages to NPM only states

Copyright (c) Microsoft Corporation.

in this regard.

It's unclear whether or not these two license files are meant to be different, but I thought that I should bring it to your attention (if you weren't already aware).

Sometimes DT contributors add a package.json to a package that does not really need one. We should check for that.
Possible example: DefinitelyTyped/DefinitelyTyped#55834

See DefinitelyTyped/DefinitelyTyped#44805 (specifically https://travis-ci.org/github/DefinitelyTyped/DefinitelyTyped/builds/688383681).

The expected behaviour is that DefinitelyTyped/DefinitelyTyped@06eb285 is not needed when those files are referenced only using typeof import(…).

I am developing an npm package, which can install type packages automatically when user exec npm install xxx or yarn add xxx, but now i suffers from no good type query interface.

I kown the search-json https://typespublisher.blob.core.windows.net/typespublisher/data/search-index-min.json , but its size is very large, requesting it will be very slow. And i notice the query page migrates from https://microsoft.github.io/TypeSearch/?search= to https://www.typescriptlang.org/dt/search?search= which use Algolia.

So is there an interface for those in need like me to query?

Sorry for my poor En.

This issue serves as an area for me to trigger Actions while I develop them.

Platform: Windows 10
Node version: 14.16.1
Npm version: 7.10.0

After printout of Installing NPM dependencies. the script terminates, it seems the installDependencies functions is called with an empty array, this worked just a couple days ago.

In DefinitelyTyped/DefinitelyTyped#52591, this resulted from a misunderstanding about what to do when the source package is deprecated. The error message for this new check should explain that source package deprecation doesn't necessarily mean that the DT package should be deprecated.

test-all should find a dependency from styled-components-react-native to styled-components, but misses it. Here is the code:

// tslint:disable-next-line:no-single-declare-module
declare module "styled-components/native" {
    // ...

Probably the code that inspects declare module doesn't expect nested modules.

Hello, Emotion contributor here. 👋 We have been using dtslint to check our (rather complex) TypeScript definitions against multiple versions of TypeScript.

The problem is that the dtslint README indicates that dtslint has moved into DefinitelyTyped-tools, and DefinitelyTyped-tools is not intended for public consumption.

How are library authors supposed to test their types against multiple TypeScript versions? (When the types are in the library's repository rather than DefinitelyTyped.)

Here are some options I have considered, though none of them seem particularly good:

1. Library authors use @definitelytyped/dtslint, even though it is not intended for public consumption.
2. Someone forks dtslint and starts maintaining it again.
3. Someone creates a new tool that enables testing against multiple TypeScript versions.
4. Each library that needs to test on multiple TS versions writes a script that "manually" installs different TS versions from npm.
5. Library authors give up on testing against multiple TS versions and instead test against a specific version or tag, e.g. the latest supported TS version (3.9 currently), typescript@latest, or typescript@next.

In module-info.ts:imports, ImportType is not a handled SyntaxKind. But they should behave the same as an import declaration.

This caused a problem in DefinitelyTyped/DefinitelyTyped#32891 which had to be fixed in DefinitelyTyped/DefinitelyTyped#33030 by adding a triple-slash reference, for example.

Hi, I wonder if the install function can be exposed so that any typescript version can be installed.

Sometimes I hope to test the generated DTS with some old versions to check compatibility, but I found the installAllTypeScriptVersions only installs the shipped and next versions.

If the install function could be exposed, it would enable us to install any needed version.

Regards.

To support betas, it would be nice to allow, for example, a v7 directory while the main directory stays at an earlier version.

1. The main directory should retain the latest tag.
2. It would also make it clearer to contributors which are the main typings to contribute to.

I would like to write this for the dependencies of wordpress__plugins

        "paths": {
            "@wordpress/*": ["wordpress__*"]
        }

But I have to write this today:

        "paths": {
            "@wordpress/data": ["wordpress__data"],
            "@wordpress/components": ["wordpress__components"],
            "@wordpress/element": ["wordpress__element"],
            "@wordpress/plugins": ["wordpress__plugins"],
            "@wordpress/rich-text": ["wordpress__rich-text"]
        }

Seems like it should be reasonably easy to support at least simple globs.

@definitelytyped/utils requires "tar-stream": "1.6.2" which requires "bl": "^1.0.0" which has a Remote Memory Exposure vulnerability

Please, consider upgrading tar-stream in order to fix this vulnerability.

Programs (especially new ones) that wants to fit in Linux should use the XDG dir standard instead of just dropping a new directory in the user home. The standard can be seen here: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

It would be nice to move the .dts directory to its appropriate place

npm run test-all in DefinitelyTyped package is failing when the changed package has dependents

for example
DefinitelyTyped/DefinitelyTyped#57500
DefinitelyTyped/DefinitelyTyped#57501
DefinitelyTyped/DefinitelyTyped#57502

the error is

Could not find config file at: .../DefinitelyTyped/node_modules/@definitelytyped/dtslint/bin/dtslint.json

i debugged this and think the issue is with this line
https://github.com/microsoft/DefinitelyTyped-tools/blob/master/packages/dtslint/src/lint.ts#L38

the lint.js is located in dtslint/bin/src/lint.js, but the dtslint-expect-only.json is in dtslint (outside of the bin)

thus path.join(__dirname, "..", "dtslint-expect-only.json") could not find the dtslint-expect-only.json

I'm working on the type definitions for https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/iobroker and while doing so, I'm stumbling over a check error where dtslint with TS4.7 seems to ignore the namespace of a type:

ERROR: 332:5  expect  [email protected] expected type to be:
  ioBroker.Object | null
got:
  Object | null
ERROR: 336:5  expect  [email protected] expected type to be:
  ioBroker.Object | null
got:
  Object | null

All other tested TS version seem to work fine. Even IntelliSense on TS4.7 shows the correct type:

#40061 is a good example that tries to remove v0 of puppeteer. I think this is something that explicitly needs to be allowed, where we previously thought it was fine to keep the old versions around.

It apparently does not, because DefinitelyTyped/DefinitelyTyped@13bb6b2 broke publishing without breaking tests.

When this package updates to include new versions of the typescript package, and those versions are not published to npm, it causes dtslint not to work.

For example, at the time of this writing, there is no version 3.5 or 3.6 published. However, when dtslint uses TypeScriptVersion.all to seed the generation of package.json files in the installer, those version numbers are used for the typescript dependency, and then npm install ... is run in those directories. This causes dtslint to fail with the following error:

npm ERR! notarget No matching version found for [email protected]
npm ERR! notarget In most cases you or one of your dependencies are requesting
npm ERR! notarget a package version that doesn't exist.

This is an important issue for maintainers who use dtslint to verify their type definition files. I happen to maintain @slack/web-api, which depends on dtslint for this reason. We hit this issue here: https://travis-ci.org/slackapi/node-slack-sdk/jobs/538163092.

I'm not sure where else definitelytyped-header-parser is used, so perhaps this is more of an issue for dtslint, but there were no changes in that package which directly caused this issue. Please feel free to close in favor of the issue I will create in that repo as well.

@definitelytyped/utils requires "tar": "^2.2.2" which has an Arbitrary File Creation/Overwrite vulnerability.

Please consider upgrading it order to fix this vulnerability.

If the required form is really required, then the merge bot shouldn't even look at it, it should just make the CI builds fail.

@andrewbranch Just curious why noDiff was added to the completionsAvgCV metric? It's not obvious to me from the history ...

The publish tool should not be overwriting previously published packages.
https://docs.npmjs.com/policies/unpublish
Overwriting published packages is against npm's policy, and I'm not sure how this was even possible because the npm registry should be immutable.

Our stable CI pipeline has failed to build since this PR was merged
DefinitelyTyped/DefinitelyTyped@5f1a949

We are using @types/react-redux 7.1.16. That npm package was originally published 9 months ago, but overwritten 6 days ago.
https://www.npmjs.com/package/@types/react-redux/v/7.1.16

I started looking into some of the other packages that would have been affected by that same PR.
https://www.npmjs.com/package/@types/chai-enzyme/v/0.6.7
https://www.npmjs.com/package/@types/emoji-mart/v/3.0.4
https://www.npmjs.com/package/@types/enzyme/v/3.10.8

All @types packages affected by the above PR have their previously published npm packages overwritten 6 days ago.

Related to DefinitelyTyped/dt-mergebot#248: when this was discussed, the conclusion was that there's no good way to guess when an owner approval is required, and therefore the header should be extended with an optional field for the required approval level. The value should be owner or maintainer.

(Maybe for completeness allow other too? The parser can just ignore the actual value, and leave that for the mergebot to decide what to do with it.)

Continuation of microsoft/types-publisher#431.

Current state

When you import from a package hosted in the DefinitelyTyped repository in a package that's also hosted in DefinitelyTyped, the types publisher will automatically declare a direct dependency on that types package matching any version. For example, if you have a package react-library that imports from react then the package.json of @types/react-library will look something like this:

{
  "name": "@types/react-library",
  "dependencies": {
    "@types/react": "*"
  }
}

Problems

Combination of the described problems are encountered in

• facebook/react#24304
• DefinitelyTyped/DefinitelyTyped#59839
• DefinitelyTyped/DefinitelyTyped#59820
• DefinitelyTyped/DefinitelyTyped#59841

duplication of @types/* packages

Given an existing module graph similar to

[email protected] /home/eps1lon/Development/throwaway/types-peer-deps
├─┬ @types/[email protected]
│ └── @types/[email protected] deduped
└── @types/[email protected]

If you want to upgrade to React 18 you would need to update @types/react with npm install @types/react@18.
However, npm (and yarn and probably other package managers) make sure that this install does not alter the dependency tree too much (if you're using lockfiles). What you end up with is something like

[email protected] /home/eps1lon/Development/throwaway/types-peer-deps
├─┬ @types/[email protected]
│ └── @types/[email protected] 
└── @types/[email protected]

Now your dependency tree contains multiple version of a types package. In this specific case these packages are incompatible.
To fix, one would have to apply one of the workarounds described in facebook/react#24304 (comment) which isn't trivial at all.
After all, package managers are supposed to resolve these issues. But they can't if we provide them with inaccurate information.

* is not forwards compatible

While currently published packages might work perfectly fine with all published versions of @types/react at the time, there's no guarantee that continues to work. It essentially requires that no breaking changes are made at all which defeats the purpose of SemVer major releases.

Proposal

Allow peer dependencies

React is generally a peer dependency and therefore it types should as well.
If we could move @types/react from dependencies to peer dependencies with

"peerDependencies": { 
  "@types/react": "*"
},

we would ensure types deduplication since the package owner would defines the version of @types/react a single time (via dependencies or devDependency.

Allow constraining @types/* dependencies to something stricter than *

Either let maintainers decide the range manually or infer the range from the versions it's currently tested on. For example, @types/react-library runs tests with @types/react v15, v16, v17 and latest. In that case we check what version the current release has (or will be) and declare that.
This way an update to @types/react-library will also bump versions of dependencies and therefore propagate bug fixes and features of those dependencies upon release.

related issues

• DefinitelyTyped/DefinitelyTyped#33015
• DefinitelyTyped/DefinitelyTyped#56011
• microsoft/types-publisher#431

Recently, the deprecation of

"noUiSlider": {
  "libraryName": "noUiSlider",
  "asOfVersion": "15.0.0"
}

broke publishing because @types/nouislider needed to be deprecated in favour of nouislider. However, the case mismatch was not caught by CI and the publisher failed when requesting the uppercase versions from npm.

dts-critic already downloads the package and depends on (parts of) DT-tools, so it's probably the best place to add this. Would have prevented the need for DefinitelyTyped/DefinitelyTyped#52789 by failing CI on DefinitelyTyped/DefinitelyTyped#52668

Example: DefinitelyTyped/DefinitelyTyped#59519 (failing in https://github.com/DefinitelyTyped/DefinitelyTyped/runs/5726980310?check_suite_focus=true)

styled-components was correctly identified to depend on react-native. However, dependencies of styled-components weren't installed so tests are failing.

The @types packages (and particularly whether dependencies should be regular deps or peer deps, big subject) is a bit messy in terms of dependency graph. I was wondering if you had a rough idea what would the absolute best case look like, assuming an ideal world where perfect solutions exist.

For example, would it be peer dependencies everywhere? Regular deps everywhere? A bit of both? Unlisted dependencies? A separate dependency field that package managers would understand (typedDependencies or whatever)? No more @types package and .d.ts into every package? The package manager downloading the types without needing markup?

Even as a thought experiment I think it can be interesting to hear your opinion about "split ecosystems" such as what TypeScript users experience.

When preparing a contribution for DefinitelyTyped, one should run npm test <pkg> which runs

[email protected] test
dtslint types "<pkg>"

Errors printed by linting rules still point into the https://github.com/Microsoft/dtslint/blob/master/docs/ <rule> path but the main readme says the repo has moved here. The URLs should be updated too.

Mapping react to react/v16 in react-virtualized-select and mapping react to react/v17 (new in DefinitelyTyped/DefinitelyTyped#56210) currently throws the following when running npm run test-all:
"react-virtualized-select depends on react-virtualized, which has a path mapping for react/v17. react-virtualized-select must have the same path mappings as its dependencies."

This constraint isn't really reflective of how peer dependencies work.
react-virtualized-select has a peer on React 16. react-virtualized has a peer on React 16 or 17. react-virtualized-select depends on react-virtualized.
This is perfectly fine at runtime by installing React 16.

But for some reason the definitions-parser thinks that's not ok. What's the reasoning behind that?

And behave reasonably in this state. There are a lot of packages owned by one person, and they may want to remove themselves in case they can no longer maintain the package.

The types-publisher service sometimes hangs indefinitely while cloning DefinitelyTyped and has to be restarted manually. That’s bad.

This crash brought down both CI and publishing, which should not happen. It might not be the fault of the parser.

// Type definitions for non-npm package css-typed-object-model-level-1 20180410.0
// Project: https://www.w3.org/TR/css-typed-om-1/
// Definitions: https://github.com/DefinitelyTyped/DefinitelyTyped
// Minimum TypeScript Version: 3.9

With the error

Error: At 2:50 : Expected one of
        /(, )|(,?\r?\n\/\/\s\s+)/
        /\r?\n\/\/ Definitions by: /

The corrected header is:

// Type definitions for non-npm package css-typed-object-model-level-1 20180410.0
// Project: https://www.w3.org/TR/css-typed-om-1/
// Definitions by: Nathan Shively-Sanders <https://github.com/sandersn>
// Definitions: https://github.com/DefinitelyTyped/DefinitelyTyped
// Minimum TypeScript Version: 3.9

See the breaking PR here: DefinitelyTyped/DefinitelyTyped#45076
and the fix commit here: DefinitelyTyped/DefinitelyTyped@f64a42d

Types-publisher is still trying to remove @types/google-cloud__storage even though it's already gone.

Currently this hangs the server instead of crashing it too, because of the setInterval I used to try again. But when the interval fires, updateOneAtATime refuses to run again because the closed-over boolean doesn't get reset with the callback throws.

For example, composer-concerto is at 0.71, as is @types/composer-concerto. But the source package has shipped its own types since 0.32! Right now, deprecation can't happen until composer-concerto adds a version that is 0.72 or higher.

We need a way to deprecate @types/composer-concerto as-is. Perhaps it would be OK to publish a deprecated 0.71.1, since presumably all users of the types also have the same version of the source package. But we'd need to think through the implications.

I've created PR here DefinitelyTyped/DefinitelyTyped#41418, which fails CI build check as the package version is prelease one (previously it was tagged as alpha, now as rc): 1.0.0-rc.2.
The check fails because of strict version check, which does not coerce prelease versions as in https://github.com/npm/node-semver/blob/70d9fb3f1c128227a3cd911867edb07a54260cad/classes/semver.js

Is that version check outcome expected (I'd close the issue) or should it be somehow addressed?
Thanks!

Somehow similar, already tracked issue:
https://github.com/microsoft/types-publisher/issues/696