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
would also produce two re-exports... although only one is actually valid... so this is definitely something to keep in mind 😕
The lexer is content-unaware so I don't think much could be done to avoid the above arguably incorrect result, even if nesting was kept into account (which might be a stretch in the lexer) that would still not always generate perfect results, for example when parsing code like this:
(maybe instead of expanding reexports there could be a new field in the parse result? as extra-reexports or something like that that could host all the reexports excluding the last one? so keeping the same exact functionality the lexer has now whilst also providing callers with the extra bit of information?)
More context
To give a bit more context, I am simply trying to parse cjs code and gather informations about all the exports and re-exports that the code contains, unfortunately as mentioned in the issue the lexer currently doesn't return all possible re-exports but only the last one encountered, this is problematic in my use case as I would want to know all possible re-exports as well (and that information gets, as far as I can tell, completely lost).
The text was updated successfully, but these errors were encountered:
The problem I'm facing is that parse only reports the last re-export of cjs modules completely loosing the information about pre-existing ones.
For example by parsing the following code:
only the last re-export assignment is recognized and reported to the caller (
reexports = ['./b.cjs' ]
).It would be very useful if all the re-exports in the code could be recognized and reported to the caller
For example as:
reexports = ['./a.cjs', './b.cjs']
The above anyways could be considered ambiguous since the same result could be obtained by parsing
so maybe
reexports
could/should actually be an array or array of strings?Meaning that parsing
could yield
reexports = [['./a.cjs', './b.cjs' ], ['./c.cjs', './d.cjs' ]]
Minimal Reproduction
For convenience I've created a reproduction here: https://github.com/dario-piotrowicz/cjs-module-lexer-reexports-repro
Additional information
Bug?
As I mentioned, I am not sure if this could be considered a bug since the reexport resetting seems to be intentional.
Solving this might generate different problems
If this issue were to be addressed, I would imagine that the following code:
would also produce two re-exports... although only one is actually valid... so this is definitely something to keep in mind 😕
The lexer is content-unaware so I don't think much could be done to avoid the above arguably incorrect result, even if nesting was kept into account (which might be a stretch in the lexer) that would still not always generate perfect results, for example when parsing code like this:
(maybe instead of expanding
reexports
there could be a new field in theparse
result? asextra-reexports
or something like that that could host all the reexports excluding the last one? so keeping the same exact functionality the lexer has now whilst also providing callers with the extra bit of information?)More context
To give a bit more context, I am simply trying to parse cjs code and gather informations about all the exports and re-exports that the code contains, unfortunately as mentioned in the issue the lexer currently doesn't return all possible re-exports but only the last one encountered, this is problematic in my use case as I would want to know all possible re-exports as well (and that information gets, as far as I can tell, completely lost).
The text was updated successfully, but these errors were encountered: