After implementing the package-json-redirects strategy in a larger project I found VSCode import suggestions were having suggesting the wrong files. This repository seemed like a great way to test with a small example, but I haven't been able to complete one or two and see suggested imports any of the three packages from the node-11-resolution or node-16-resolution projects.

Do you happen to know what I might be doing wrong, or why these projects don't complete for me?

The package-json-redirect README describes separate types for CJS and ESM files also being possible with the package.json redirect strategy.

Note that the separate handling of ESM and CJS, as well as the decision to present a unified set of types for the two, is orthogonal to the subpath exports demonstration. (Including separate types for CJS and ESM files, as extensionless does, is often a better choice, and is compatible with this strategy.)

How is this compatible, with just one types field of the package.json would that be accomplished with two sets of types in a redirected-to directory with .d.mts and .d.ts extensions? And the types field should have no extension?

When I type it out it seems obvious, I guess my confusion was around which file extensions tricks were unique to the "extensionless" approach.

I was having trouble getting import suggestions to show up in VSCode for the Node11 package so don't have a repro here (feel free to close), but in another project following the package-json-redirects strategy I found that I still needed to use something like the types-versions-wildcards approach

"typesVersions": {
  "*": {
    "entrypoint1": "./dist/types/entrypoint
    ...
}

to get reasonable import completion in VSCode.

Without this, I was getting import completions to the types files themselves, things like import {something} from "packagename/dist/something".

If there's something to understand it would be useful to add it to the matrix, is there anything obvious about how VSCode might be confused by package-json-redirects? Again I did not repro this in this repo, so this is likely my mistake — but I wasn't able to rule it out because I didn't get import completion working in the Node11 package.

Not an issue with this repo per se, but I just wanted to point out that Parcel will have proper support for exports mappings in an upcoming release: see parcel-bundler/parcel#8807.

Once this question gets answered,

https://stackoverflow.com/questions/77856692/how-to-publish-plain-jsjsdoc-library-for-typescript-consumers

it will be nice to put an example here.

There is also not enough information to figure how to achieve it in these two TS doc pages:

• https://www.typescriptlang.org/docs/handbook/modules/reference.html
• https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html

It will be nice to update those too.

https://github.com/andrewbranch/example-subpath-exports-ts-compat/blob/main/examples/node_modules/types-versions-wildcards/package.json has both main and exports defined. But the solution works only for Node >= 12. Wouldn't it make sense to remove main then to keep it simpler and avoid any confusion?

Hello,

With the arrival of TS 5.0 option --moduleResolution bundler, could you add an example using this value? I am mainly confused on what to put in package.json field main and equivalent exports since we are not producing .js files?

Regards,
Bruno