Typings for the `main` and `browser` property in package.json

[Gijsjan]

Search Terms

package.json typescript browser main isomorphic multiple typings

Suggestion

I have asked a question on StackOverflow (https://stackoverflow.com/questions/53847688/types-field-in-package-json-for-browser-and-main-field), but I have not gotten any reactions and now I'm wondering if it is at all possible. Hence a feature request.

Use Cases

I have build an isomorphic lib, to be used in node and the browser (HuygensING/xmlio). NPM has a solution for that, using the main and browser properties in package.json. But, there is only one typings property. How to specify two different typings? One for the browser and one for node?

[weswigham]

If your package has different types in node vs the browser.... have you considered that you really have two separate packages? We assume that a single package has a single API.

[typescript-bot]

This issue has been marked as 'Question' and has seen no recent activity. It has been automatically closed for house-keeping purposes. If you're still waiting on a response, questions are usually better suited to stackoverflow.

[verhovsky]

This is a feature request, not a question, so you should at least re-tag it as "Won't Fix".

I am looking at converting my JS package to TypeScript and in my package I'm loading a dependency that has a version for node and a WASM version for the browser. I npm install both versions and then the difference for my package using npm's browser package.json field is just a trivial "on the browser import and initialize this package, on node import this one instead":

https://github.com/curlconverter/curlconverter/blob/289aa2a85cbcea7cd4ffa365cd6dd4bf0c705aef/parser.js

https://github.com/curlconverter/curlconverter/blob/289aa2a85cbcea7cd4ffa365cd6dd4bf0c705aef/browser-parser.js

https://github.com/curlconverter/curlconverter/blob/289aa2a85cbcea7cd4ffa365cd6dd4bf0c705aef/package.json#L46

I like doing it this way because then all my code (which is otherwise the same between node and browser) can live in a single repository and I don't want users of my package to have to know about that dependency or to know that there's a node and a browser version of my package.

[lobsterkatie]

We similarly could use this in our Next.js SDK. Any library built for an isomorphic framework like Next is likely to run into this.

Also:

If your package has different types in node vs the browser.... have you considered that you really have two separate packages? We assume that a single package has a single API.

Until the node and browser APIs are identical, I don't think this is a fair criticism.

[aultac]

I know this is old, but +1 from me. I've written a few universal libraries, and this is the single biggest feature missing from Typescript for me. The main key in package.json has an override of browser for the browser, so for Typescript to be correct it needs a browser-types key that goes with browser and specifies the typings for the browser.

For example, I have a universal library that reads and writes files. The node version cannot use the HTML5 File type in its API because it doesn't know anything about those. Yet, the browser-based code needs to use that type because you can't just give a function a filename in the browser and have it read the contents.. You need to give it a File object chosen by a file chooser dialog.

So there is a node-specific fromFile(filename: string) and a browser-specific fromFile(file: File). The only solution is to either require the user to include browser-specific and node-specific index files from dist/node/index.js and dist-browser/browser/index.js, or make the types all any in the universal API, which defeats the purpose of Typescript.