I looked into what it will take to run search in the extension host using extension APIs.

• Ripgrep search
  • Just need to port ripgrepTextSearch.ts and ripgrepFileSearch.ts
  • Currently it downloads the correct ripgrep binary at build time. A builtin extension in the core repo can still do that. A marketplace extension would have to ship all binaries and pick one at runtime.
  • Dependencies
    • Has lots of trivial dependencies from vs/base/common. It's ok to copy them, move to native node versions, or native ES versions
    • glob.ts, but we should get rid of that dependency. It's only used for sibling clauses and those should be handled on the frontend
  • API
    • Doesn't expose all features that builtin search needs
      • Whether to use gitignore file
      • Follow symlinks
      • Max filesize
      • Encoding (can be read from files.encoding, do we expect all
        extension authors to think of that?)
      • Result limit count (handled by frontend using CancellationToken?)
      • Searching outside of the workspace
      • Smart case (front end)
      • wordSeparators (front end)
      • Cache search (for file search)
      • Sort by score (for file search)
      • Multiroot search (change it to search per single folder)
    • Need to read RelativePattern, instead of the current IFolderQuery
  • Logging
    • Use extensionhost logger and output pane
  • Frontend changes - SearchService just need to talk to search provider API
• Non-rg search is harder
  • Need glob.ts, and all of its dependencies
  • Mime
  • Iconv and the stuff we have built around it
  • IPC stuff from core for spawning worker processes
  • All of the dependencies would have to be moved to a separate node module so they can be shared with search. We probably don't want to do that.