The documentation states:

fastmod is supported on macOS and Linux.

Is there a reason for this support policy? I tested out fastmod on windows and it seems to work fine. I also skimmed the code base for any unixisms and the only one I could find was assuming $EDITOR was set/defaulting to vim.

I am wondering if it would be possible publish fastmod to Docker Hub in some official capacity, so that it could be used verbatim in the Sourcegraph batch changes spec?

This whole batch changes codemodding framework is container-based, similar to how Google Cloud Build configs work:

https://docs.sourcegraph.com/batch_changes/quickstart#write-a-batch-spec

Is this something Facebook ever does for other open source tools? I realize this can be done unofficially fairly easily, but an official image would be nice.

For example, https://github.com/comby-tools/comby/ is published to https://hub.docker.com/r/comby/comby (well, no wonder, since the main author is at Sourcegraph :) )

If the user selects 'n' (to skip a match), the next comparison only starts one character later. If the beginning of the patch pattern, is, e.g. '( +)' this may continue to find the same match many times. I've added logic that starts the search from the end of the previous match, if the user skips the last change. This is not very well tested, so feel free to review it.

In our codebase we have some committed .env files (it's a separate question whether that's a good idea or not...).

➜  fastmod-dot-env ls -al
total 16
drwxr-xr-x   4 konradkomorowski  staff  128 25 May 14:52 .
drwx------@ 25 konradkomorowski  staff  800 25 May 14:50 ..
-rw-r--r--   1 konradkomorowski  staff    4 25 May 14:50 .foo
-rw-r--r--   1 konradkomorowski  staff    4 25 May 14:52 foo
➜  fastmod-dot-env cat .foo 
bar
➜  fastmod-dot-env cat foo 
bar

I noticed that fastmod will ignore those:

➜  fastmod-dot-env fastmod --accept-all bar baz
➜  fastmod-dot-env cat .foo 
bar
➜  fastmod-dot-env cat foo 
baz

things work fine if I'm directly targeting that file:

➜  fastmod-dot-env fastmod --accept-all bar baz .foo 
➜  fastmod-dot-env cat .foo 
baz

But sometimes I don't know what the filenames will be (as in the case of the codemod we were running), and we are 100% confident that we want to just replace all substrings.

I tried options like -g **/* and -g */** but that didn't work.

What's the motivation for this behavior? Is there a workaround that I'm not aware of?

PS: here's my version

➜  fastmod-dot-env fastmod --version
fastmod 0.4.1

$ cat b
#!/bin/bash
t () {
    echo bla;
    return $?
}

# Next command should have been: "fastmod '\$\?' '$?;' b" instead, but:

$ fastmod '\$?' '$?;' b
thread 'main' panicked at 'byte index 18446744073709551615 is out of bounds of `#!/bin/bash
t () {
    echo bla;
    return $?
}
`', src/libcore/str/mod.rs:2131:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

$ RUST_BACKTRACE=1 fastmod '\$?' '$?;' b
thread 'main' panicked at 'byte index 18446744073709551615 is out of bounds of `#!/bin/bash
t () {
    echo bla;
    return $?
}
`', src/libcore/str/mod.rs:2131:9
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:77
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1052
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1426
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:204
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:224
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:472
  11: rust_begin_unwind
             at src/libstd/panicking.rs:380
  12: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
  13: core::str::slice_error_fail
             at src/libcore/str/mod.rs:0
  14: core::str::traits::<impl core::slice::SliceIndex<str> for core::ops::range::RangeTo<usize>>::index::{{closure}}
  15: fastmod::index_to_row_col
  16: fastmod::fastmod
  17: fastmod::main
  18: std::rt::lang_start::{{closure}}
  19: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:52
  20: std::panicking::try::do_call
             at src/libstd/panicking.rs:305
  21: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:86
  22: std::panicking::try
             at src/libstd/panicking.rs:281
  23: std::panic::catch_unwind
             at src/libstd/panic.rs:394
  24: std::rt::lang_start_internal
             at src/libstd/rt.rs:51
  25: main
  26: __libc_start_main
  27: <unknown>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

This workflow is the same as @lunaryorn's Mdcat -- kudos to him !

It is triggered when a release is created with a tag named 'v something', e.g. v1.1.0.

You can see the results on my own fork here.

The 3 builds for Linux, MacOS and Windows run fine, but I've only tested the Linux one.

This PR also creates a CHANGELOG.md file, to be included in the released packages.

This PR adds an option to configure the amount of threads that the directory iterator will use. It doesn't close any issues but rather removes a "TO DO" left in the code.

Hi and thank you for open sourcing fastmod!

I was trying to use it to replace

try {
  await thing.start()
} catch (e) {
  console.error(e)
}

with just

await thing.start()

I assume giving enough effort with the multiline regex I could solve it, but I was wondering there would be interest to have a parameter that would accept a simpler pattern in a file?

Something like fastmod -p pattern-file "replacement \${1}"

pattern-file could contain something like

try {
  $1
} catch (e) {
  console.error(e)
}

Everything else would remain the same 😄

The solution to this is probably to support -g/--glob like ripgrep, since we use the ignore crate to implement --extensions anyway and we could just implement -g with passthrough to ignore.

Problem

This came up when I was trying to do a version bump this way:

fastmod --hidden --ignore-case '(poetry.*)1\.2\.2' '${1}1.3.2'

I set the --hidden flag in order to also match asdf's .tool-versions file (needs to be included in the version bump).

However, I found fastmod matching files in the .git/ folder - which is something I definitely do not want to mess with (it was matching some of the previous commits where I performed the version bump to 1.2.2):

./.git/.graphite_cache_persist:128
        }
      ],
      [
        "poetry",
        {
          "validationResult": "VALID",
          "parentBranchName": "main",
          "parentBranchRevision": "3deb75c540a0daeb29986e3ef3cc36e07b8f07b0",
          "branchRevision": "fce724219a729bfb03b8bdd93035872c56f26dfd",
          "children": [],
          "prInfo": {
            "title": "upgrade poetry to 1.2.2",
-           "body": "Run this to catch places where our current poetry version is mentioned after the string \"poetry\":\n\n```\nfastmod --hidden --ignore-case '(poetry.*)1\\.2\\.1' '${1}1.2.2'\n```\n",
+           "body": "Run this to catch places where our current poetry version is mentioned after the string \"poetry\":\n\n```\nfastmod --hidden --ignore-case '(poetry.*)1\\.2\\.1' '${1}1.3.2'\n```\n",
            "number": 280,
            "url": "https://app.graphite.dev/github/pr/exponential-hq/expo/280",
            "base": "main",
            "state": "OPEN",
            "reviewDecision": "REVIEW_REQUIRED",
            "draft": false
          }
        }
      ]
    ]
  }
Accept change (y = yes [default], n = no, e = edit, A = yes to all, E = yes+edit, q = quit)?

(In this case it was a graphite file, rather than a vanilla git file, but I don't think it matters.)

I suspect that I could somehow use the --glob flag to exclude the directories I wanted, but it's not obvious to me how to do it in an elegant and reliable way.

Potential solution 1

Wdyt about having a flag to explicitly exclude some directories?

Similar to how comby has --exclude and --exclude-dirs: https://comby.dev/docs/cheat-sheet

Potential solution 2

Or have a mode where only files tracked by git would be modified by fastmod? I presume that .git is implicitly ignored by git when doing source control, so that could be also implicitly assumed as well.

I know that Facebook uses Eden now, but maybe you can consider being aware of git too, as nod to the open source community.

Bumps thread_local from 1.1.3 to 1.1.4.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.