floral hawk
I am depending on a package that includes its implementation and type information in a single package. I only want to use the type information. The implementation causes errors at runtime because a modified version is already provided by my framework. Unfortunately, my framework doesn't provide the types.
How do I get the types without getting the implementation?
Should I just copy and paste its index.d.ts into my own package and depend on it directly?
ripe coral
Just do import type { AType } from 'a-package'
type is optional, if you import only types that is all you will get, but using it will make sure you only import types, and raise an error otherwise. It also helps when there are values and types with the same name.
@floral hawk
floral hawk
I think even if I do that the package will be added to mine
ripe coral
What does package added to yours mean? node_modules? bundle?
You can add it as a dev dependency. You obvious do need the package in your node_modules during development, after that you don't.
floral hawk
The implementation causes problems in the bundle and when running tests
floral hawk
What does package added to yours mean? node_modules? bundle?
bundle
tree shaking should solve the bundle issue, but it's still an issue when running tests
ripe coral
Hmm, when you compile TS, any imports that are only types are removed
import type only imports declarations to be used for type annotations and declarations. It always gets fully erased, so there’s no remnant of it at runtime. Similarly, export type only provides an export that can be used for type contexts, and is also erased from TypeScript’s output.
So unless you are using a build system that is compiling TS incorrectly, I don't see a problem there.
Maybe if you are testing with ts-node? Is it an issue then?
Even so if you only import type it can't have any runtime effect
floral hawk
So those imports won't be there during transpilation, but a bundler could still add the package into the build
ripe coral
Why would it?
A bundler has to map the dependencies between files to understand what to bundle and where I think. Including only what you use should be a basic feature
And the dep can be a devDependency. It's not going to include all your dev dependencies in the output is it?
floral hawk
A bundler has to map the dependencies between files to understand what to bundle...
I think you are referring to tree shaking (a feature of bundlers). That would indeed remove the package from my build
ripe coral
Tree shaking refers to only using the parts of the modules that are used. So it will go through files and remove unsused functions and exports
No bundler is going to be dumb enough to just bundle your whole node_modules folder
A simple bundler will follow imports to find which files you use and include them (requires an import to it). A more advanced bundler can strip away unused parts of those files too.
cedar silo
Yeah, I'm pretty sure TS will remove the import before the code even hits the actual bundling logic.
ripe coral
Yes, he's saying a bundler could still include it in the bundle even without any imports to it.