Typesync throwing getaddrinfo ENOTFOUND typespublisher.blob.core.windows.net

[cw-alexcroteau]

A typesync run throws getaddrinfo ENOTFOUND typespublisher.blob.core.windows.net. I don't have more details for now, but could provide a sample repo if needed.

[fmoyaj]

Same here. Please take a look.

[jeffijoe]

Its possible Microsoft moved or stopped supporting that endpoint. I’m not home until next week so can’t look into it until then. If someone could help me out by figuring out what happened to that resource and if there is an alternative, that would speed things up for when I’m able to cut a release.

[bmerigan]

I'm adding a "me too" to this reported issue.
I've never looked at or worked with Azure endpoints before. Did find some info here: https://github.com/microsoft/DefinitelyTyped-tools/tree/master/packages/publisher#debugging-azure But following the listed steps didn't get me anywhere except to confirm it's down - which we knew. I raised an issue there too.

-  Syncing type definitions in package.json...
x  getaddrinfo ENOTFOUND typespublisher.blob.core.windows.net

[asif-simform]

Same here. Please take a look.

asif@1.73.1 postinstall typesync

» TypeSync v0.9.2

• Syncing type definitions in package.json... ✖ getaddrinfo ENOTFOUND typespublisher.blob.core.windows.net Stack: Error: getaddrinfo ENOTFOUND typespublisher.blob.core.windows.net at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:71:26) npm ERR! code 1 npm ERR! path /home/runner/work/asif npm ERR! command failed npm ERR! command sh -c typesync

[hardik-simform]

TypeSync v0.9.2

We are also facing the same issue and our CICD pipeline is not working now.

Error: getaddrinfo ENOTFOUND typespublisher.blob.core.windows.net     at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:71:26)

[choudlet]

Yeah our CICD pipeline is also broken due to this issue and this library being consumed from a different library. Thanks for raising that issue with microsoft @bmerigan.

[anaetrezve]

Facing same issue on OSX

[jakajancar]

Guys... the server this library depends on disappeared. Yeah, your CI/CD pipeline or OS X are no exception in being affected.

The maintainer replied in the third reply, told you he would not be able to immediately address this, and also told you how you can help... which writing "me too" (for the tenth time) does absolutely not.

[nbdavies]

See related issue here: https://github.com/microsoft/DefinitelyTyped-tools/issues/668

[bmerigan]

Update from the issue I raised with Microsoft. The source is not coming back.
Also they removed mention of it from the README.

This was never public API, and hasn’t been getting updated since 2020 anyway. (https://github.com/microsoft/DefinitelyTyped-tools/pull/51/files#diff-de7516b7f088e6c0b8ec69aee38be709e7d309719cb6f2c504280cd3c257c05dL21) We finally deleted all the associated resources yesterday. But yeah, the data was 3 years stale.

The author of TypeSync will need to find another source, or possibly make one using info at https://github.com/microsoft/DefinitelyTyped-tools/tree/master/packages/publisher Though from the 2020 comment, I'm wondering if this package has been providing any value.

[jakebailey]

The thing that yarn's typescript plugin uses is to just check npm; the types packages have a consistent naming scheme, so for foo you can check for @types/foo, and for @some/package you can search for @types/some__package.

(Technically they have an algolia index but the idea is still the same.)

[jeffijoe]

One issue I see is that the current implementation relies on the .g field to know whether a typings package exposes globals (such as jQuery). This was used to prevent removing seemingly unused typings packages, so I don't think we can keep supporting that feature if we need to use npm directly.

[jakebailey]

Hm, I could have sworn that info was present in the published package.json files, but it apparently isn't.

[jeffijoe]

I also just looked at the Algolia index and they don't have it either.

[jeffijoe]

TypeSync v0.11 has been released.

npm i -g typesync

[MartinKolarik]

@jeffijoe I see you already worked around this in a different way, but just in case this is useful to you in any way: we (jsDelivr) have just published a package that has a list of all the @types packages in one file (repo, cdn).

It was built primarily for the Algolia npm search index so it doesn't currently have all the fields (we didn't need them) but I think it would be possible to add them if anyone found it useful.

[jeffijoe]

Thanks for the heads-up @MartinKolarik!

[jakebailey]

It seems like the index isn't quite right, e.g.:

{
  "p": "https://github.com/aredridel/node-bin-gen",
  "l": "node",
  "t": "node"
},

FWIW there already is https://www.npmjs.com/package/types-registry which provides a snapshot on DT's current contents, though not packages which have been removed (but not deprecated for compat reasons). For this package, I do think directly querying npm is a better idea...

[MartinKolarik]

FWIW there already is https://www.npmjs.com/package/types-registry which provides a snapshot on DT's current contents, though not packages which have been removed (but not deprecated for compat reasons).

Cool, I somehow didn't come across that one.

It seems like the index isn't quite right, e.g.:

That's indeed an unfortunate consequence of mixing up npm and non-npm packages in one namespace and using a naive package matching approach 😄

[jakebailey]

It's pretty much guaranteed that you can unmangle the type package name and get back to its actual npm package; there are a few exceptions to that rule, though. I am of course intrested in what you are needing this data for, but I don't want to spam this thread 😄