feature: alternate package entry points

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]

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

[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.