babel-plugin-transform-inline-imports-commonjs
babel-plugin-transform-inline-imports-commonjs copied to clipboard
* Added plugin options "includeModules" and "moduleMatchType"
The main purpose of this pull-request is to make it so this plugin can be added incrementally to a project, only converting imports to inline-requires for "trouble" modules.
The includeModules option takes care of the incremental/partial inlining, and the moduleMatchType option makes it usable for project files instead of just npm package modules in the node_modules folder.
I've tested the change in my project and it's working well. (though eventually it might be even better to let the user mark individual import statements as to-be-inlined, as it gives more fine-grained control for those wanting to minimize the number of imports they inline)
Commit message:
-
Added plugin option "includeModules". When specified, the
excludeModulesoption will be ignored, and modules will only be inline-imported if they're in this list. -
Added plugin option "moduleMatchType", which specifies how to compare the
import/requirecalls' sources (the string argument) with the include/exclude list values. Example: Switch to"ends with", and set the include or exclude list to["/node_modules/atom"], if you want the plugin to work for relative imports likerequire("../node_modules/atom"). [makes it usable for project modules instead of just node_modules ones]
Hmm, 2 of the 69 tests appear to be failing, which is odd. I looked back over the changes, and from what I can tell, it shouldn't modify the behavior unless the new options are actually specified/enabled.
I tried looking at the test-runner's debug log, but it doesn't seem to actually show which of the tests are failing, making it hard to know where to look.
Do you know how I can get more detailed logs to track down the issue? (sorry, new to continuous-integration testing)
@Venryx, I like the idea, but not moduleMatchType. I'm file if it takes regex and/or some filter function. I understand that this makes it not possible to use from a babelrc, but that's the price of configurability. Using magic words like exact or ends with is pretty clunky.
Fair enough; that would make it more flexible. (and less unstable/arbitrary)
If/when I have the time, I'll look into changing it to use regexes and/or filter functions.