feature: alternate package entry points

[jorroll]

Please describe the feature/suggestion

Many packages offer alternate entry points (e.g. lodash-es/map, rxjs/operators, @rschedule/core/rules, etc). At the moment, it appears that bundlephobia only supports scanning they main entry point of a package (e.g. rxjs).

It would be awesome if, when searching for packages on bundlephobia.com, there was a way of specifying that an alternate entry point should be used. E.g. rxjs/operators@6.5.3

[pastelsky]

While I agree that this is a problem, I don't see too many packages doing this.

Did you check out the new Exports analysis feature launched in Bundlephobia? I think more package authors are moving in the direction of exporting these as ES6 named modules from the default entry point.

Case in point the examples you listed above (scroll down to find the Exports Analysis section) –

https://bundlephobia.com/result?p=lodash-es@4.17.15
https://bundlephobia.com/result?p=rxjs

[jorroll]

@pastelsky I had not seen the new exports analysis feature! That's very cool!! This being said, the feature looks (almost) unrelated to this request. There are some packages which export everything from the main entry point, in addition to utilizing (somewhat redundant) alternate entry points. For example, lodash-es does this (I think to support people who don't want to use a build system). Also, @angular/material currently does this, but the main entry point is deprecated and will be removed in version 9.

Rxjs, however, does not do this. For example, the export analysis for rxjs does not contain any of the exports from rxjs/operators.

It's possible I feel the need for this feature more because it's something I run into frequently using Angular, which has many packages utilizing alternate entry points.

A few additional angular examples:

• @angular/common/http
• @angular/common/upgrade
• @angular/materal/... (angular material has many alternate entry points)
• @angular/platform-browser/animations
• @angular/fire/... (and, separately, firebase/...)
• ...

A few reasons for using alternate entry points

1. A package has optional dependencies. Code paths which make use of the optional dependencies must be moved into an alternate entry point.
2. A package has optional code which produces side effects. The optional, side-effecting code must be moved into an alternate entry point.
3. A package author wishes to support smaller bundle sizes for folks not using tree-shaking (I think lodash-es falls into this category).

While reason #3 is technically an optional choice on the part of the package maintainer (and could be removed in favor of exporting everything from the main entry point), reasons number 1 and 2 require alternate entry points.

[pastelsky]

Fair enough. About #3 though – a package author can still ship both different entry points, as well as named exports.

Good news is, bundlephobia's core already supports something like this. For the most part things will just work. The part that is going to fail right now is parsing or package strings. Today a string like

rxjs@2.0.0

will simply be split at the @ symbol and a package name and version is derived. Then on, the package and its version is resolved from the npmjs registry.
We would need to make the parser smarter about this, and instead give us the package name, import path as well as the package version.

I'm open to taking PRs for this and guide you towards the changes required if your're interested

[jorroll]

Awesome 👍 . This probably isn't something I'm interested in working on, but perhaps in the future that'll change.

[markerikson]

Would be really neat to see this added.

We're adding a new "RTK Query" API in Redux Toolkit 1.6. The import entry points will be:

// Existing UI-agnostic APIs
import { createSlice } from "@reduxjs/toolkit";
// RTKQ features, UI-agnostic
import { createApi as genericCreateApi } from "@reduxjs/toolkit/query";
// RTKQ features, with React-specific functionality baked in
import { createApi as reactCreateApi } from "@reduxjs/toolkit/query/react";

The RTK Query entry points will add an additional size chunk to a user's app, and it would be nice to show and distinguish that from the contents of the root entry point.