npm type support not working for main field in package.json is not index.js

[shfshanyue]

For example: https://badgen.net/npm/types/markdown-read

[vladimyr]

Peek inside markdown-read manifest reveals that types field is missing and the actual index.d.ts lives inside dist folder: https://npmfs.com/package/markdown-read/2.2.6/dist/

According to TypeScript publishing documentation there is no way for other tools to discover included typings because they aren't properly advertised. As a result official typings search tool also fails to discover it: https://www.typescriptlang.org/dt/search?search=markdown-read

I don't think this is a badgen.net bug, try adding "types": "./dist/index.d.ts" to your manifest 💡

[shfshanyue]

git-upstream-template is an alternative package，and actual index.d.ts lives inside dist/src folder: https://unpkg.com/browse/[email protected]/dist/src/

Typescriptlang and npmjs.com both discover included typings. It's main field is "main": "./dist/src/index.js", may be discover it using ./dist/src/index.d.ts other than index.d.ts. I will submit a PR if possible

links:

• https://badgen.net/npm/types/git-upstream-template
• https://github.com/rioam2/git-upstream-template
• https://www.typescriptlang.org/dt/search?search=git-upstream-template
• https://www.npmjs.com/package/git-upstream-template
• https://unpkg.com/browse/[email protected]/dist/src/

https://unpkg.com/${pkg}/index.d.ts could be https://unpkg.com/${pkg}/${meta.main.replace(jsType, 'd.ts')}

 // https://github.com/badgen/badgen.net/blob/master/api/npm.ts#L194
 async function typesDefinition(pkg: string, tag = 'latest') {
   let meta = await pkgJson(pkg, tag)

   if (typeof meta.types === 'string' || typeof meta.typings === "string") {
     return {
       subject: 'types',
       status: 'included',
       color: '0074c1'
     }
   }

   const hasIndexDTSFile = await got.head(`https://unpkg.com/${pkg}/index.d.ts`)
     .then(res => res.statusCode === 200)
     .catch(e => false)

   if (hasIndexDTSFile) {
     return {
       subject: 'types',
       status: 'included',
       color: '0074c1'
     }
   }
   // ... other code
}

[vladimyr]

Ok, let me first start with saying that I really appreciate constructive answers backed with factual research, big kudos for that 👍

However, here is the thing, correct me if I'm wrong but both typescriptlang.org type search server component and npm's server API aren't opensource so we can't really peek into it and see how they resolve typings. Alternatively, we might do either:

1. Implement your proposal
2. Copy what shields.io did: https://github.com/badges/shields/blob/ddc9ee5/services/npm/npm-type-definitions.service.js#L40-L60

and I'm kind of reluctant to do any of those two things due to the following reasons. Your approach is sound but is something you came up with, it isn't backed by spec or precedence in other words it is non-standard and we should avoid those things if we can. OTOH shields.io folks are essentially playing the guessing game and it is too easy to trick that check.

What I would like to do instead is to reuse the typescript's own resolution algorithm. I'm guessing that logic we need to extract is buried somewhere inside this code: https://github.com/microsoft/TypeScript/blob/v4.2.2/src/compiler/moduleNameResolver.ts

If you have few free cycles to burn any help is more than welcome.