Node browser resolution strategy

Question

Node browser resolution strategy

blakeembrey opened this issue 10 years ago · 11 comments

I'd like to propose a new resolution strategy that builds upon node resolution to support https://github.com/defunctzombie/package-browser-field-spec - node+browser. The core differences is that it reads package.json/browser to select the entry point or module "aliases". For example, browser can point to a string that is used in place of main when resolving or specific a map of keys to values - where the key is a relative path or a module name and the value is a boolean, relative path or module name.

This module resolution is used in Browserify by default, and can be enabled in Webpack using https://webpack.github.io/docs/configuration.html#resolve-packagealias. It's the primary way to develop and distribute universal packages that work on node and in browsers.

Edit: It would also be amazing to have the compiler handle this when developing packages so that the aliases are type-checked to be compatible in both environments. For example, it could catch serviejs/popsicle#47.

Answer 1 · 2016-04-01T17:48:08.000Z

Wouldn't it be common that the node and browser version have the same types? Some implementations might differ, but API should behave the same.

Answer 2 · 2016-04-01T18:35:43.000Z

Ideally, yes. That's the best way to implement universal packages. There's still enough difference if you need to do browser that there's probably some API differences - especially with environment features/APIs.

Answer 3 · 2016-07-04T03:00:31.000Z

+1
We need this for Universal Angular 2. Universal provides a ton of helpers for node in order to connect the two worlds (server/browser) in a seamless way. This involves writing similar types that have different dependencies depending on which environment you're currently in. Right now, if you use the browser version of universal you're presented with types that do not exist yet TypeScript is suggesting that it's valid

Answer 4 · 2016-11-15T23:10:20.000Z

Starting to see it in some other universal projects (aside from my own), most notably the AWS SDK (aws/aws-sdk-js#1228).

Answer 5 · 2016-11-16T01:17:06.000Z

This is also a problem for Angular's use of Ahead of Time compiler which uses TypeScript's extensibility feature. When splitting code per platform there must be two paths created

angular2-universal/browser
angular2-universal/node

https://github.com/angular/universal-starter/blob/master/src/app/app.browser.module.ts#L3

Answer 6 · 2017-04-18T22:36:33.000Z

Nothing new here? I'm trying to make AoT working with package.json main/browser split and it's almost imposible.
I'm feeling tempted to write my own hack around here or even contribute if the team is willing to accept a PR

Maybe a tsconfig with the array of fields to lookup in order would be nice, if not provided TS can always use the defaults.

Answer 7 · 2017-05-22T19:02:56.000Z

sadly you have to create 3 code paths

import 'your-package' <-- universal interface
import 'your-package/browser' <-- browser interface
import 'your-package/server' <-- server interface

Answer 8 · 2017-06-27T01:24:05.000Z

We just ran into this again with TypeDoc. We're using the Handlebars type definitions which relies on DOM typings, but none of the package runs in the browser so won't need DOM types.

Answer 9 · 2017-06-30T15:08:43.000Z

👍 for this.

Answer 10 · 2021-10-09T17:01:48.000Z

I would also like to see this. I'm writing a library that has a slightly lighter API for the browser than for Node, and while the Node typings of my library are a strict superset of the browser typings in my specific case, I'm still concerned that consumers targeting browsers may infer an incorrect API based on being presented with Node types. (This would be a much bigger concern for libraries where the browser API is larger than the Node API, since browser consumers would be missing types for supported API features unless they manually remapped the library types themselves.)

Supporting the browser field would mean Typescript could automatically present the same view of a package's API that common bundlers use:

Browserify uses the browser field by default
Webpack uses the browser field when resolving modules by default
Rollup's plugin for Node module resolution, @rollup/plugin-node-resolve, supports the browser field through an option (though it's off by default, Rollup is used to bundle for Node.js targets more frequently than the others, so it makes sense to manually have to opt into browser resolution)

I've never contributed to Typescript before, but I think this is something I'd be willing to work on, if nobody else is already working on anything in this area. Is there anything I should know or anything about this feature we'd want to flesh out before starting?

Answer 11 · 2024-03-04T23:06:31.000Z

I can barely make sense of things written in the module landscape of 2016 anymore, but I think this effectively solved with us supporting custom conditions in package.json