-- Single-source-of-truth helper for project-local run/debug configs, meant
-- to be called once per config from a project's `.nvim.lua` (requires
-- `opt.exrc` - see options.lua - and trusting the file once via
-- `:help :trust`). One call registers both an overseer run task and a
-- matching nvim-dap debug config, so a project states its command once
-- instead of repeating it across a separate run-file and debug-file.
--
-- Example .nvim.lua (script invocation):
--   require("config.project_run").python({
--     name = "Run app",
--     program = vim.fn.getcwd() .. "/main.py",
--     args = { "--flag" }, -- optional, shared by both run and debug
--   })
--
-- Example .nvim.lua (module invocation, `python -m <module>`):
--   require("config.project_run").python({
--     name = "Run app",
--     module = "fastapi",
--     args = { "dev", "app" },
--   })
--
-- This shows "Run app" in the <leader>rr picker (plain execution) and in
-- the <leader>dc picker (same script/module, under debugpy, breakpoints
-- included). If <cwd>/.venv exists, both get VIRTUAL_ENV/PATH pointed at
-- it, same as `uv run` (or `source .venv/bin/activate`) would - and the
-- debug config additionally gets pythonPath set to that venv's interpreter,
-- since debugpy runs the script with the literal interpreter it's told
-- rather than resolving `python3` via PATH.
--
-- Example .nvim.lua (Node, script invocation):
--   require("config.project_run").node({
--     name = "Run app",
--     program = vim.fn.getcwd() .. "/index.js",
--     args = { "--flag" }, -- optional, shared by both run and debug
--   })
--
-- Example .nvim.lua (Node, `npm run <script>` invocation):
--   require("config.project_run").node({
--     name = "Run app",
--     npmScript = "dev",
--   })

local M = {}

local function venv_dir()
  local venv = vim.fn.getcwd() .. "/.venv"
  if vim.fn.isdirectory(venv) == 0 then
    return nil
  end
  return venv
end

local function venv_env(venv)
  return {
    VIRTUAL_ENV = venv,
    PATH = venv .. "/bin:" .. vim.env.PATH,
  }
end

function M.python(opts)
  assert(opts.name, "project_run.python: opts.name is required")
  assert(opts.program or opts.module, "project_run.python: opts.program or opts.module is required")

  local venv = venv_dir()
  local env = venv and venv_env(venv) or nil
  -- Resolve the interpreter to the venv's own binary rather than relying on
  -- env.PATH below: jobstart/libuv resolves a bare "python3" against the
  -- *parent* process's PATH, not the child job's env, so a PATH override
  -- alone silently falls through to the system interpreter.
  local python = venv and (venv .. "/bin/python3") or "python3"
  local cmd = opts.module and { python, "-m", opts.module } or { python, opts.program }

  require("overseer").register_template({
    name = opts.name,
    builder = function()
      return {
        cmd = cmd,
        args = opts.args,
        name = opts.name,
        env = env,
      }
    end,
  })

  local dap = require("dap")
  dap.configurations.python = dap.configurations.python or {}
  table.insert(dap.configurations.python, {
    type = "python",
    request = "launch",
    name = opts.name,
    program = opts.program,
    module = opts.module,
    args = opts.args,
    env = env,
    -- nvim-dap-python only auto-detects an interpreter (VIRTUAL_ENV env var,
    -- then a venv/.venv/env/.env folder search) when pythonPath/python isn't
    -- already set - and debugpy needs the literal interpreter path here
    -- regardless, same reason `cmd` above uses the venv binary directly
    -- rather than a bare `python3` resolved via env.PATH: it spawns the
    -- interpreter directly, not through a shell that'd do that resolution.
    -- Set it explicitly from the same .venv we already found, so debugging
    -- doesn't depend on that separate heuristic agreeing with us - without
    -- this, a missed/wrong guess falls back to debugpy's own adapter venv,
    -- which can't see the project's installed packages.
    pythonPath = venv and (venv .. "/bin/python") or nil,
  })
end

-- Node has no venv-style interpreter juggling to do - node_modules
-- resolution is automatic - so this is a straight translation of opts into
-- an overseer task plus a pwa-node dap config, into all four JS/TS
-- filetypes (dap_node.lua registers the same four for its own defaults).
function M.node(opts)
  assert(opts.name, "project_run.node: opts.name is required")
  assert(opts.program or opts.npmScript, "project_run.node: opts.program or opts.npmScript is required")

  local cmd = opts.npmScript and { "npm", "run", opts.npmScript } or { "node", opts.program }

  require("overseer").register_template({
    name = opts.name,
    builder = function()
      return {
        cmd = cmd,
        args = opts.args,
        name = opts.name,
      }
    end,
  })

  -- A fresh table per filetype - nvim-dap's session setup can stash
  -- bookkeeping fields onto a running config, so the four filetypes
  -- shouldn't share one table instance.
  local function config()
    local c = {
      type = "pwa-node",
      request = "launch",
      name = opts.name,
      args = opts.args,
      cwd = vim.fn.getcwd(),
    }
    if opts.npmScript then
      c.runtimeExecutable = "npm"
      c.runtimeArgs = { "run", opts.npmScript }
    else
      c.program = opts.program
    end
    return c
  end

  local dap = require("dap")
  for _, filetype in ipairs({ "javascript", "typescript", "javascriptreact", "typescriptreact" }) do
    dap.configurations[filetype] = dap.configurations[filetype] or {}
    table.insert(dap.configurations[filetype], config())
  end
end

return M