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
The source analysis doesn't currently expose reexport analysis, primarily because the use cases haven't shown a pressing need for this currently.
We did previously discuss that it is a requirement for detecting things like ambiguous errors, but that this is not a use case we necessarily need to support for the source analysis.
Creating this issue to track if there are use cases we are missing here further.
The text was updated successfully, but these errors were encountered:
Current strawman is for the following extensions to exports objects in addition to the existing export property added in #21:
For all exports to get the additional local property which may be undefined:
local the name of the local binding to be able to dedupe multiple exports of the same binding
And then for reexported bindings to extend the above with import and module:
import the name of the imported binding. Possibly null for export * as ns from './x.js'
module the imported module specifier string in the case of import
The idea then is that analysis would enumerate each export value, coalescing as necessary so that eg import * as ns from 'x'; export { ns as x, ns as z } would be represented as [{ export: 'x', local: 'ns', import: null, module: 'x' }, { export: 'z', local: 'ns', import: null, module: 'x' }].
Whether we do proceed with this either as part of this proposal or a subsequent one still depends on determining if the full ambiguous analysis use cases are needed.
The source analysis doesn't currently expose reexport analysis, primarily because the use cases haven't shown a pressing need for this currently.
We did previously discuss that it is a requirement for detecting things like ambiguous errors, but that this is not a use case we necessarily need to support for the source analysis.
Creating this issue to track if there are use cases we are missing here further.
The text was updated successfully, but these errors were encountered: