Sometimes the relative paths in source code don't line up to what they'll be in production.
Example
Suppose our source code is organized like this
/js/main.js
/js/path/to/lib/index.js
However, in production, the paths will be
/js/main.js
/js/lib/index.js
We have two ways to go about this.
1. Use production path in source
We can import using
// js/main.js
import lib from './lib/index.js'
and set up our dev server to rewrite/redirect. Any build tools will also need to have suitable configuration.
This plugin currently won't be able to find the source file and cannot calculate the hash. (afaik, Babel doesn't support path mapping, so there's no way this plugin will be able to find the file using Babel's global config.)
2. Use the source path
We could also import using
// js/main.js
import lib from './path/to/lib/index.js';
Now the plugin can find the file and add the hash. However, we'll need to rely on another plugin (or build tool) to change the module name from ./path/to/lib/index.js to ./lib/index.js.
Solution
I will implement a solution for option #1.
The primary reason is that the whole point of this module (for me) is to be able to use source files in production with as little tooling as possible.
With a plugin configuration like
{map: {
"lib": "path/to/lib"
}}
the tool can leave the module name path as-is, but will still be able to find the source file in order to calculate its hash.
Sometimes the relative paths in source code don't line up to what they'll be in production.
Example
Suppose our source code is organized like this
However, in production, the paths will be
We have two ways to go about this.
1. Use production path in source
We can import using
and set up our dev server to rewrite/redirect. Any build tools will also need to have suitable configuration.
This plugin currently won't be able to find the source file and cannot calculate the hash. (afaik, Babel doesn't support path mapping, so there's no way this plugin will be able to find the file using Babel's global config.)
2. Use the source path
We could also import using
Now the plugin can find the file and add the hash. However, we'll need to rely on another plugin (or build tool) to change the module name from
./path/to/lib/index.jsto./lib/index.js.Solution
I will implement a solution for option #1.
The primary reason is that the whole point of this module (for me) is to be able to use source files in production with as little tooling as possible.
With a plugin configuration like
the tool can leave the module name path as-is, but will still be able to find the source file in order to calculate its hash.