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
I work for a large company with a large code base and I've recently integrated flow into our build process. So far we're loving it and it has been very useful. One problem, however, we're facing is that our build process will look for a given module locally, if it doesn't find it, it will fall back to another directory where it should be found. I've mostly worked around this, as a hack, using the module name mapper, but it's really not a satisfactory solution. In my personal side projects, I have encountered similar issues working with modules. Build processes leave a lot of room for the custom resolution of modules - more than Flow could ever account for on its own. I'd like propose a configuration option for a custom module resolver. This option would be provided a command. It could be something like node somescript.js or custommoduleresolver, or even custommoduleresolver.exe, depending on the environment. The command would then be passed arguments for the script-in-question's path (or that could be the current working directory) and the module which it is trying to resolve. The resolver would output an absolute path to the correct module for Flow. There could be an option for only resolving modules that Flow cannot resolve on its own as well. Another possibility is that, for performance, the resolver is only executed if the process is not already running and accepts input from Flow while it runs. I think as the ever complex JavaScript ecosystem grows, this will increasingly become a necessity. Thoughts?
The text was updated successfully, but these errors were encountered:
I work for a large company with a large code base and I've recently integrated flow into our build process. So far we're loving it and it has been very useful. One problem, however, we're facing is that our build process will look for a given module locally, if it doesn't find it, it will fall back to another directory where it should be found. I've mostly worked around this, as a hack, using the module name mapper, but it's really not a satisfactory solution. In my personal side projects, I have encountered similar issues working with modules. Build processes leave a lot of room for the custom resolution of modules - more than Flow could ever account for on its own. I'd like propose a configuration option for a custom module resolver. This option would be provided a command. It could be something like
node somescript.js
orcustommoduleresolver
, or evencustommoduleresolver.exe
, depending on the environment. The command would then be passed arguments for the script-in-question's path (or that could be the current working directory) and the module which it is trying to resolve. The resolver would output an absolute path to the correct module for Flow. There could be an option for only resolving modules that Flow cannot resolve on its own as well. Another possibility is that, for performance, the resolver is only executed if the process is not already running and accepts input from Flow while it runs. I think as the ever complex JavaScript ecosystem grows, this will increasingly become a necessity. Thoughts?The text was updated successfully, but these errors were encountered: