-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Regex creation problem through command line interface #37
Comments
Hi there, would the solution for you perhaps be to use a configuration file with the regex in there instead of passing them via the command line? That would support more complex use cases. If you want to create a PR for this change though feel free to open one and I'll review it there. Would be good to have unit tests for it somehow as well. |
Thanks for your reply! I tried using a configuation file. I guess it would work. Also, it would allow me to call replace-in-file only once per file since I put both regular expressions in there. But the CLI resolves the configuration file path relatively to the current "working folder", which is deeper than my utils folder, no matter if I prepend a slash or not. It makes no sense for me to reprogram the entire batch file so that the working folder is my utils folder. I assume using node.js instead of a Windows batch file would definitely be better and more flexible... |
Happy to look into it if you provide more details about your folder structure and use case. You can still use the CLI but have it use a configuration file. I think you can put that configuration file anywhere you'd like, from memory. |
replace-in-file being installed globally, please consider the following folder/file structure:
Excerpt from the Windows batch file:
Result is that it tries to load the configuration file like this:
instead of:
Sure, in that use case, it would be easy to rewrite the batch file, but later on it looks deeper into other folders and subfolders, where JS and CSS folders and files might not exist, all of this using for loops and exist commands to trigger uglify-js, csso and replace-in-file accordingly. That being said, until we review our deployment process, I have to make-do with this batch file way of doing it. Maybe I am doing something wrong, but I found out that the configuration helper uses path.join with the process.cwd() and the file. May it use another method or use only the file when it begins with a slash? |
@connelly-steve you are right, I have addressed this in 3.1.0 by using Please note that if you specify files in the config file, they will still be resolved related to the current working directory, not the path where the config file sits. Also note in your example that when you call the CLI, you don't need to specify the |
@adamreisnz, thank you for the update! I removed 'from' and 'to'. I had left them in there although I had a configuration file because I was also specifying the file to search. The command line interface kept on asking for 3 arguments. I moved the file to search in the configuration file, used the '--configFile' argument alone and now the command line interface seems happy.
But still, I get this error:
Here is my 'replace-in-file.config.js':
|
Hi @connelly-steve, the config file is module.exports = {
from: [
/"sources":\[".*\\\\(.+.css)"\]/g,
/"file":".*\\\\(.+.css)"/g
],
to: [
"\"sources\":[\"../../src/css/$1\"]",
"\"file\":\"../../src/css/$1\""
],
files: "../../dist/css/*.min.css.map"
}; |
It works! Thank you! |
Awesome, let me know if there's anything else. |
Will close this now, but if you have any other issues feel free to reopen or create a new issue. |
Hi!
I need to replace source file paths in CSS source maps I create using a Windows batch file. I am glad I found this tool, but I had trouble getting regex search to work. Here is an example of my final answer:
But, to achieve this, I had to modify 'cli.js' to better split the pattern and flags:
Before this change, I had problems with slashes and flags, whether I used flags, a trailing slash or neither of them. Furthermore, I believe logging 'options.from' makes it more transparent than logging 'from'.
The text was updated successfully, but these errors were encountered: