There are some instances where one might want to modify where to look for a node_module. One such case is when the module is migrated into the final dist/lib folder. In my specific use case, it's for using a node_module with the k6 library from Grafana. It runs a subset of NodeJs functionality that cross-compiles into Go code. As such, you cannot rely on importing code from node_modules. To work around this, we write the code with the normal importing from node_modules, but before the code is built we copy the relevant modules into a subdirectory of the source.
I originally thought this plugin would allow us to transform those paths, such as import { sum } from '@utils' as a very rough example, by setting up the tsconfig as follows:
I expected this to convert the final path to ./src/@utils. However, setting the path like so would only tell this transformer to convert the path from @utils to its location under node_modules, instead of the path that I defined. This PR is an attempt to resolve that.
There are some instances where one might want to modify where to look for a node_module. One such case is when the module is migrated into the final dist/lib folder. In my specific use case, it's for using a node_module with the k6 library from Grafana. It runs a subset of NodeJs functionality that cross-compiles into Go code. As such, you cannot rely on importing code from node_modules. To work around this, we write the code with the normal importing from node_modules, but before the code is built we copy the relevant modules into a subdirectory of the source. I originally thought this plugin would allow us to transform those paths, such as
import { sum } from '@utils'
as a very rough example, by setting up the tsconfig as follows:I expected this to convert the final path to
./src/@utils
. However, setting the path like so would only tell this transformer to convert the path from@utils
to its location undernode_modules
, instead of the path that I defined. This PR is an attempt to resolve that.