[context] build package files are not accessible

[klasjersevi]

Which package(s) are affected?

Context (@lit/context)

Description

The build files in the lib/directory of the package can't be used when using modern import because they are not provided in the exports section of package.json.

In my case I try to use the following, which fails when building.

import { ContextProviderEvent, type Options } from "@lit/context/lib/controllers/context-provider.js";

Adding "./lib/*": "./lib/* to "exports" in package.json would allow any file in the lib/to be imported.

  "exports": {
    ".": {
      "types": "./development/index.d.ts",
      "development": "./development/index.js",
      "default": "./index.js"
    },
    "./lib/*": "./lib/*"
  },

Reproduction

1. Set up a standard typescript project using Vite or similar.
2. Import something from a file in the lib directory of @lit/context in a .ts file in the project.

import { ContextProviderEvent, type Options } from "@lit/context/lib/controllers/context-provider.js";

3. Build the project by running vite build.

Workaround

Specify an alias for the file in vite.config.js.

    resolve: {
      alias: {
        "@lit/context/lib/controllers/context-provider.js": "./node_modules/@lit/context/lib/controllers/context-provider.js",
      },
    },

Is this a regression?

No or unsure. This never worked, or I haven't tried before.

Affected versions

@lit/context@1.1.1

Browser/OS/Node environment

Lit 3.1.3
Typescript 5.4.5
Node v20.10
Vite v5.2.9

[augustjk]

I wasn't as involved at the creation of this package but I'd imagine omitting /lib/ from package exports is intentional and things meant for end-user consumption are only exposed via the package root pointing to index.js. It's also (subjectively) easier for the user not having to worry about internal package structure.

It's a valid point though whether ContextProviderEvent and Option should also be exported from the package and I think the answer is yes?

Option types are useful for users wanting to pre-construct. We might do that for both ContextProvider and ContextConsumer which would require aliasing the the interface to something like ContextProviderOptions and ContextConsumerOptions.

I can't imagine why you'd want to manually create the ContextProviderEvent but I suppose it's possible to manually dispatch those instead of using the controller. I see the package already exports ContextRequestEvent albeit with an alias (not sure why) so I don't see the harm in exporting the provider event.

@justinfagnani might have more context (😉) on what the intended exports were.

[klasjersevi]

I'm guessing it's non-intentional since it's a rather new feature/effect connected to moduleResolution in typescript. The files are totally accessible if you are using an older build system, that only use the main field or similar instead of the exports. Like Webpack 4 vs Webpack 5.

In our project it took a while to discover that this addition is needed in the "exports" since it's a rather new limitation that is only respected by some build systems. But now we have everything in our package available and usable. The things we want to restrict for some reason are not included in the package at all and available in the source repo instead.

Why I want to import these is because I'm extending the ContextProviderclass with some minor custom functionality (related to #4414). To be able to provide a proper constructor in the extending class, I need some of the exports in context-provider.

My current workaround (since the alias-workaround not fully worked unfortunatley) is actually just copying some of the raw files from the lib directory in the npm package instead.

I would be totally fine if everything was exported in the index instead, but I guess it would be very easy to miss something.