Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Map src to types with package exports #70

Merged
merged 1 commit into from
Mar 21, 2025
Merged

Map src to types with package exports #70

merged 1 commit into from
Mar 21, 2025

Conversation

platypii
Copy link
Collaborator

This should fix #69 but want to get your thoughts @severo

From my research there were two ways to fix this. The first was typescript-specific and felt more hacky:

  "typesVersions": {
    "*": {
      "src/*": ["types/*"]
    }
  },

It seemed like the better way was to explicitly define package exports and associate types with the default exports vs file exports:

  "exports": {
    ".": {
      "types": "./types/hyparquet.d.ts",
      "import": "./src/hyparquet.js"
    },
    "./src/*.js": {
      "types": "./types/*.d.ts",
      "import": "./src/*.js"
    }
  },

There was also some choice between "import" and "default" but since we only export ESM modules, import seemed like the right choice.

I tested these locally with npm pack and dependency on "hyparquet": "../hyparquet/hyparquet-1.9.1.tgz",. It appears to fix the type issue in #69.

Finally, I'll probably publish this as 1.9.2 because this is a type fix, not an API change? I could be convinced if you think it should be 1.10.0 though? (I wouldn't be surprised if this breaks something and someone subesquently files an issue due to unforeseen build process).

@platypii platypii requested a review from severo March 20, 2025 23:48
Copy link
Contributor

@severo severo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perfect!

We could even remove main and types as top-level fields since they are obsolete, and export should be the only entry point to access the package files.

Re version: the thing that could break is if somebody was importing the types as:

import type {ParquetType} from 'hyparquet/types/constants.d.ts'

since you cannot access hyparquet/types/... anymore now (the route is through hyparquet/src/... now)

So, probably better to change the version to 1.10.0

@platypii platypii merged commit b9ad12f into master Mar 21, 2025
6 checks passed
@platypii platypii deleted the package-exports branch March 21, 2025 11:55
@platypii
Copy link
Collaborator Author

I wonder does this means we can remove the ../src/ in all the type imports?

@severo
Copy link
Contributor

severo commented Mar 21, 2025

In the jsdoc comments? Yes, I guess it would work if we replace ../src/ with ./

@severo
Copy link
Contributor

severo commented Mar 21, 2025

I tried, and it works as expected in a library client, indeed.

Note that when exploring in an editor the generated files in the types/ subdirectory (in hyparquet, or in node_modules/hyparquet's client repo) after npm run build:types, the imports show an error : Cannot find module './types.d.ts' or its corresponding type declarations.ts(2307), which can be unexpected from a user point of view.

@platypii
Copy link
Collaborator Author

Yea I played around with variations of replacing ../src/ with ./ but ran into errors with typed.d.ts being in src instead of types directory. Same thing you saw. I couldn't find a better solution so I'm not going to make that change. Will publish v1.10.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Types are not correctly associated with deep file imports
2 participants