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

Option to define an allow list for generating declaration/declarationMap #47111

Open
5 tasks done
zen0wu opened this issue Dec 11, 2021 · 3 comments
Open
5 tasks done
Labels
In Discussion Not yet reached consensus Suggestion An idea for TypeScript

Comments

@zen0wu
Copy link

zen0wu commented Dec 11, 2021

Suggestion

πŸ” Search Terms

build mode, declarations, d.ts

βœ… Viability Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

It would be great tsconfig.json can expose a set of keys to say, "these are the only types that will be exported" from this module, and don't generate .d.ts for the rest.

πŸ“ƒ Motivating Example

When building under --build, TSC emits .d.ts for every single TS file in the module, but intuitively it only needs to
generate declaration files for the ones that's cross module boundary (so that other modules when referencing it),
which is likely a very small subset of types defined in the entire module.

πŸ’» Use Cases

We have this problem where trying to switch build mode, TSC generates huge type declarations for files who are not
even referenced by other modules at all. The emit time is extremely high and incremental build is barely usable.

Sometimes it's not even possible to build-ify a project, if I have a module that,

export const thirdPartyLib = await import("3rd-party")

If this thirdPartyLib export a type that exposes an unimported type in its shape, we'll hit this error

error TS4023: Exported variable 'deps' has or is using name 'ElementsProps' from external module "node_modules/@stripe/react-stripe-js/dist/react-stripe" but cannot be named.

Concrete example: https://github.com/stripe/react-stripe-js/blob/master/src/components/Elements.tsx#L72

@RyanCavanaugh RyanCavanaugh added In Discussion Not yet reached consensus Suggestion An idea for TypeScript labels Dec 13, 2021
@RyanCavanaugh
Copy link
Member

RyanCavanaugh commented Dec 13, 2021

This is an interesting idea, especially since in principle we know if we're going to emit an import reference to a file whose declaration emit has been disabled

@zen0wu
Copy link
Author

zen0wu commented Dec 20, 2021

Right exactly, also this would probably reduce the emitter's job by a lot, and this change will only affect typescript, has no runtime behavior at all. Maybe we could even leverage the package.json new export map (https://github.com/jkrems/proposal-pkg-exports/)?

@zen0wu zen0wu changed the title Under build mode, only emit declaration in an allow list Allow defining an allow list for generating declaration/declarationMap Jan 2, 2022
@zen0wu zen0wu changed the title Allow defining an allow list for generating declaration/declarationMap Option to define an allow list for generating declaration/declarationMap Jan 2, 2022
@zen0wu
Copy link
Author

zen0wu commented Apr 10, 2022

Bump this - given now the support for package.json export map is rolled out, seems a perfect time to add this feature on top.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
In Discussion Not yet reached consensus Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

2 participants