You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, given an import such as import { Foo, Bar } from './utilities', the returned dependencies will only give ['utilities'], and no other details about what specifically was imported.
For example, the previous import in the page.ts file:
// Directory Structure
├── page.ts
└── utilities
├── index.ts
├── foo.ts
├── bar.ts
└── baz.ts
// utilities/index.ts
export * from './foo'
export * from './bar'
export * from './baz'
These details would be incredibly useful in other places such as dependency-tree so that the specific imports could be traced.
Currently when getting the dependencies for page.ts it would be utilities/index.ts, and utilities/index.ts would depend on foo, bar, and baz. This gives the appearance that page.ts depends on foo, bar, and baz, even though it only imports Foo and Bar.
I would be happy to PR this improvement to this package if this is an acceptable addition. When implementing it, I would add an opt-in config option to retrieve the extra import declaration data, and then pass it to the onAfterFile callback for use in other locations.
The text was updated successfully, but these errors were encountered:
Currently, given an import such as
import { Foo, Bar } from './utilities'
, the returned dependencies will only give['utilities']
, and no other details about what specifically was imported.For example, the previous import in the
page.ts
file:These details would be incredibly useful in other places such as
dependency-tree
so that the specific imports could be traced.Currently when getting the dependencies for
page.ts
it would beutilities/index.ts
, andutilities/index.ts
would depend onfoo
,bar
, andbaz
. This gives the appearance thatpage.ts
depends onfoo
,bar
, andbaz
, even though it only importsFoo
andBar
.I would be happy to PR this improvement to this package if this is an acceptable addition. When implementing it, I would add an opt-in config option to retrieve the extra import declaration data, and then pass it to the
onAfterFile
callback for use in other locations.The text was updated successfully, but these errors were encountered: