I recognize the content within the variable could be anything which would make the string a lot less useful to parse. I think it would be ok to strip content in the template string injected variable, so long as the glob were identifiable. For example, something like an asterisk replacement would work too:
{ n: '@scope/packages/intl/*/strings.js' }
This would allow the glob match to be handled dynamically.
Workaround:
The s and e args are intact, so we can slice this out in js and try to simplify to work around, but maybe it would be more efficient in the lower layer.
When parsing this import:
...it returns
{ n: undefined }
.Expected:
Returns
{ n: '@scope/packages/intl/${...}/strings.js' }
I recognize the content within the variable could be anything which would make the string a lot less useful to parse. I think it would be ok to strip content in the template string injected variable, so long as the glob were identifiable. For example, something like an asterisk replacement would work too:
{ n: '@scope/packages/intl/*/strings.js' }
This would allow the glob match to be handled dynamically.
Workaround:
The
s
ande
args are intact, so we canslice
this out in js and try to simplify to work around, but maybe it would be more efficient in the lower layer.