Skip to content
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

Ruby pack, standardrb and rubocop conflict with each other #1249

Open
4 tasks done
jyeharry opened this issue Oct 23, 2024 · 2 comments
Open
4 tasks done

Ruby pack, standardrb and rubocop conflict with each other #1249

jyeharry opened this issue Oct 23, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@jyeharry
Copy link

Checklist

  • I have searched through the AstroNvim documentation
  • I have searched through the existing issues of this project
  • I have searched the existing issues of plugins related to this issue
  • I can replicate the bug with the minimal repro.lua provided below

Neovim version (nvim -v)

0.10.1

Operating system/version

macOS 14.7

Terminal/GUI

iTerm2

Describe the bug

When using the ruby language pack, standardrb and rubocop conflict with one another.

For example, I'll get a lint warning from standardrb saying not to use spaces inside array brackets, I'll run the formatter to fix this, then I'll get a linting warning from rubocop saying I need to have spaces inside array brackets.

This is in a fresh rails 7 project that comes with rubocop config already setup. I do not have rubocop installed in mason either. I haven't configured rubocop or standardrb myself and I was under the impression standardrb is built on top of rubocop so should be compatible with it.

I created a solargraph-config.yml and in that I silenced the rubocop reporter, but then the issue I had was when pushing commits in my rails project to github, the preconfigured github ci process that comes with rails would fail due to the rubocop linting errors. I could disable the preconfigured ci step, but I figured I'd rather not go against the rails grain so instead I copied the contents of lua/astrocommunity/pack/ruby/init.lua into my own config file replacing every instance of "standardrb" with "rubocop". I now no longer get conflicting linting and the formatter goes off of rubocop rather than standardrb.

This may become an issue again if ever go to work in a ruby/rails repo that does use standardrb though. I may find myself having to change my nvim config every time I work in a repo that uses the other linter/formatter.

I'm wondering if there's a better way this pack could be designed? Perhaps one where both standardrb and rubocop are included with the ruby pack, but only standardrb is used for linting and formatting if there's a standardrb config file in the repo or only rubocop is used in any other case? Or is my limited knowledge of the ruby toolset the problem, and perhaps I'm actually supposed to do some more of this setup myself? I would've thought the pack would be set and forget though.

Steps to Reproduce

  1. Create a fresh rails 7 project
  2. Open a ruby file such as one of the controllers.
  3. Type arr = [ 1, 2, 3 ]
  4. In normal mode type gl to display the lint warnings on the line. Note the warning from standardrb Standard Ruby: Layout/SpaceInsideArrayLiteralBrackets: Do not use space inside array brackets.
  5. Address the warning either through running the formatter, by default <Leader>lf, or just removing the spaces manually
  6. In normal mode type gl to display the lint warnings on the line. Note the warning from rubocop rubocop: Use space inside array brackets.

Expected behavior

There should be no conflicting linting warnings. Ideally neovim should be able to determine which linter to use based solely off whether there's a config file for that linter in the project and if not, should default to using only one of the tools.

Screenshots

No response

Additional Context

No response

Minimal configuration

-- save as repro.lua
-- run with nvim -u repro.lua
-- DO NOT change the paths
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "runtime", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  -- stylua: ignore
  vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", "--branch=stable", lazypath })
end
vim.opt.rtp:prepend(vim.env.LAZY or lazypath)

-- install plugins
local plugins = {
  { "AstroNvim/AstroNvim", import = "astronvim.plugins" },
  { "AstroNvim/astrocommunity", import = "astrocommunity.pack.ruby" },

  -- add any other plugins/customizations here
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

-- add anything else here (autocommands, vim.filetype, etc.)
@jyeharry jyeharry added the bug Something isn't working label Oct 23, 2024
@Uzaaft
Copy link
Member

Uzaaft commented Oct 23, 2024

Perhaps the typescript pack could be of inspiration to fix this problem

@jyeharry
Copy link
Author

@Uzaaft can you be more specific? I'm not super familiar with this setup stuff, just pretty basic config stuff.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants