Unable to import package easily via PNPM or TypeScript compiler

[pospi]

I guess first question is whether or not this is already published to NPM- couldn't find it. If so, please point me in the right direction and disregard.

Have logged this as PNPM-specific, but it may not be. Regardless I don't think that the syntax in package.json's exports is being recognised as the modules given by those names (eg. @adaburrows/table-web-component/field-definitions fails to import).
Currently removing exports entirely and loading with

//@ts-ignore
import { FieldDefinitions, FieldDefinition } from '@adaburrows/table-web-component/dist/field-definitions'

serves as a workaround. I should be able to simply import as @adaburrows/table-web-component/field-definitions or at least @adaburrows/table-web-component/dist/field-definitions and have the compiled source and typedefs automatically imported though.

Note that I am referencing the module via git with "@adaburrows/table-web-component": "git://github.com/adaburrows/table-web-component#b2e4f4a" in case this is specific to git refs and may go away with NPM publication.

[adaburrows]

Hmm, I'll have to either just publish it or set up a pnpm project to use it (like maybe REA-Playspace, since that was my intent to do soon).

I don't know if pnpm just doesn't support it, but when you install a module without the @ in front of it like so in npm:

npm i --save adaburrows/table-web-component

It just fetches it from Github. Most of the workspace stuff supported by pnpm is now it npm. So there's less reason to use it except for maybe efficiency in larger projects with potentially redundant deps. However, that's still reason enough for me to continue using it.

I'll see what I can find out about this within today through next week.

[pospi]

So there's less reason to use it except for maybe efficiency in larger projects with potentially redundant deps

It simplifies dependency management in a way that NPM workspaces don't appear to in practise. The NPM workspaces I've seen tend to still operate under a "directory-first" organising principle where modules are imported via relative paths or bundler configuration. PNPM workspaces enforce a more rigorous "package-first" structure where dependencies must be explicitly managed between modules, resulting in fewer hidden surprises regarding 'hidden dependencies' from parent directories shadowing missing bindings in modules further down the directory tree.

[adaburrows]

I don't think this had much to do with npm vs pnpm. I just had a messed up package.json. I also rethought how the package exports things for certain use cases. Now, by default, each package entry point exports all the needed classes. The dist/index.js just exports the classes without registering them. The dist/react.js wraps the components to be used with React. The dist/global.js exposes the needed classes, but registers the components globally.

The new package.json exports look like this:

{
  "exports": {
    ".": "./dist/index.js",
    "./react": "./dist/react.js",
    "./global": "./dist/global.js"
  }
}

[pospi]

Reopening this, even though a slightly different symptom it's all part of the same configuration. In this case, it's not generating types for tsc to act on and I have to use a //@ts-ignore tag with the main import still.

[!] (plugin typescript) Error: @rollup/plugin-typescript TS7016: Could not find a declaration file for module '@adaburrows/table-web-component'. '/home/pospi/projects/neighbourhoods/timetracking-applet/node_modules/.pnpm/github.com+adaburrows+table-web-component@7c32f0d/node_modules/@adaburrows/table-web-component/dist/index.js' implicitly has an 'any' type.
  Try `npm i --save-dev @types/adaburrows__table-web-component` if it exists or add a new declaration (.d.ts) file containing `declare module '@adaburrows/table-web-component';`

[pospi]

Oh.. I can't reopen? Well, I'll leave it with you @adaburrows :)

[pospi]

It also gives this error, which seems a likely omission:

[!] Error: 'Table' is not exported by ../node_modules/.pnpm/github.com+adaburrows+table-web-component@7c32f0d/node_modules/@adaburrows/table-web-component/dist/index.js, imported by src/components/valueflows/TimesheetEntriesList/TimesheetEntriesList.ts

It's registered globally in global.ts as well, and not returned; I think it should be present in the exported objects for both modules in case app authors want to get a handle on globally-registered Element types for any reason. It currently does get exported from react.ts, so that file is already functioning as it should be.