Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Tree-shaking d.ts files
See original GitHub issueTree-shaking with d.ts files
Importing part of modules using the root index.d.ts file.
🔍 Search Terms
d.ts tree-shaking type import destructuring
✅ 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
Parse only the required d.ts file.
💻 Use Cases
We have several modules which uses larger modules with extensive typings, e.g aws-sdk.
When we import only S3
import { S3 } from 'aws-sdk';
aws-sdk/index.d.ts got parsed. These bigger modules can add up, increasing required resources for compilation with increased compile time.
If I import S3 directly, then the matching d.ts file parsed only:
import S3 from 'aws-sdk/clients/s3';
I did some experiment changing few of these imports and examined a few tsc traces, parse part went down for 10 seconds to 4, obviously the parsed declaration number went down accordingly.
Tried to look for various config combinations, but found nothing about this.
Issue Analytics
- State:
- Created 2 years ago
- Comments:12 (5 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Absolutely no. Or depends on the implementation of this feature, as if it requires slightly modified emitted d.ts, then yes, the corresponding @types/module has to be recompiled.
Then my module can see that it is safe or not to import only the required type from
baz, because when we initially emittedbaz(which is a separate, third party module), we examined, and decided it is totally safe to use it that way.Here is some comparison, initial build times:
This is not much, but the memory usage already a lot higher, but not compare the incremental build performance during watch:
This is now insane. Check the memory usage, the nodes count, and the build time. Nonsense. You can say, lets simply force myself to use ‘aws-sdk/clients/module’. Thats ok, as long as I don’t run into another @types/module which imports a part of
aws-sdkin its d.ts file, but using only a part of it. My build time is screwed again. And this is only one big module where tons of unused types got parsed during rebuilds@steveetm Just an observation - with libraries moving towards ESM format and that AWS library being CommonJS, it wouldn’t make sense to develop tree shaking methods for CommonJS libraries. Moreover, with an ESM lib, you could make a proxy intermediate lib using rollup - although I’m not sure that would be less work than manually tree “picking” (as you demonstrated) which is the only current way to select from CommonJS libs.