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

Libraries specified in lib in tsconfig.json should be emitted as reference directives in declarations #27416

Closed
4 tasks done
sindresorhus opened this issue Sep 28, 2018 · 2 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@sindresorhus
Copy link

Search Terms

  • lib declaration
  • lib tsconfig emitted

Suggestion

When specifying "lib": ["es2017.sharedmemory"], in tsconfig.json, I expected the output declaration files to include a reference directive to the lib, for example, /// <reference lib="es2017.sharedmemory"/>. Not doing so means that if I publish a package to npm that uses the SharedArrayBuffer type, the consumer will have to specify "lib": ["es2017.sharedmemory"], in their tsconfig.json too. This is super leaky as the original package could be used many levels deep and the requirement leaks to the top. This makes it unfeasible to use any kind of extra lib in a reusable package.

Relevant issue: sindresorhus/is#51

My current workaround is to manually add the reference directives (which is now possible in TS 3.1.1, thanks to #26497), but this doesn't scale if the package has many files.

Use Cases

Being able to use types for modern features without the consumer having to know what I'm using internally.

Examples

https://github.com/sindresorhus/is/blob/c983ffa4cd83c114b18d021c180e6ba9265070cd/source/index.ts#L181

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. new expression-level syntax)
@RyanCavanaugh RyanCavanaugh added the Working as Intended The behavior described is the intended behavior; this is not a bug label Oct 1, 2018
@RyanCavanaugh
Copy link
Member

Being able to use types for modern features without the consumer having to know what I'm using internally

This is exactly why we don't want to emit the directives as suggsted -- if you have a lib reference to something you only use for implementation, but don't expose in your .d.ts file, then this would just introduce more potential for conflicts by including unneeded libs in the referencing project. If you use es2017.xxx but someone else intends to run with a polyfill .d.ts for the xxx feature, then they're effectively blocked from doing so.

@typescript-bot
Copy link
Collaborator

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

3 participants