standardrb / standard

Ruby's bikeshed-proof linter and formatter 🚲
Other
2.69k stars 209 forks source link

Dealing with Gemfile.lock #618

Closed whysthatso closed 4 months ago

whysthatso commented 6 months ago

I think i am missing something about how to set up my linting/syntax checking, but for some reason in all my ruby projects, i get this error on the Gemfile.lock:

unexpected token tCOLON
(Using Ruby 3.3 parser; configure using `TargetRubyVersion` parameter, under `AllCops`)

this is the part in question:

  remote: https://rubygems.org/

Context:

GEM
  remote: https://rubygems.org/
  specs:

Should the file just be ignored, or what is exactly wrong here?

searls commented 6 months ago

The Gemfile.lock is not listed by default, and no default globs should be catching it. How are you running standard and what's in your .standard.yml file, if you have one?

whysthatso commented 6 months ago

so this is:

default config, no .standard.yml file

whysthatso commented 6 months ago

okay, i added a simple .standard.yml file, but that does not seem to be honored.

ruby_version: 3.3
ignore:
  - Gemfile.lock
  - tmp/**/*
  - test/fixture/**/*
whysthatso commented 6 months ago

sometimes there is a weird conflict about extensions when one has multiple sections in a workspace, but i've just opened the plain folder inside a simple vscodium instance (open vscode > open folder), and it's the same problem.

whysthatso commented 4 months ago

hang on, just to be very clear:

Gemfile.lock is not being ignored by default, right?

Reference:

https://github.com/standardrb/standard/blob/44b70610b2dcc35c037dd293044f08abe1546d9c/lib/standard/creates_config_store/configures_ignored_paths.rb#L3

https://github.com/rubocop/rubocop/blob/v0.61.1/config/default.yml#L60-L63

If it is correct, why? What is the value in linting the Gemfile? And why does it create above mentioned error?

searls commented 4 months ago

Gemfile.lock is not included in any of the default globs in RuboCop or Standard Ruby, so whatever is causing your issue must be configuration.

To show a trivial example, given this folder with two files that are both non-compliant in the same way, only the rb file raises a violation:

$ tree .
.
├── Gemfile.lock
└── bar.rb

1 directory, 2 files

$ cat bar.rb 
puts 's'
$ cat Gemfile.lock 
puts 's'
$ standardrb
standard: Use Ruby Standard Style (https://github.com/standardrb/standard)
  bar.rb:1:6: Style/StringLiterals: Prefer double-quoted strings unless you need single quotes to avoid extra backslashes for escaping.
standard: Run `standardrb --fix` to potentially fix one problem.
djchadderton commented 4 months ago

I get the same for Gemfile.lock, i.e. this in VSCode:

unexpected token tCOLON
(Using Ruby 3.3 parser; configure using `TargetRubyVersion` parameter, under `AllCops`) (fatal:Lint/Syntax)

The first colon in remote: https://rubygems.org/ at the top of the file is marked as the source of the error.

I'm using the official StandardRB VSCode extension, and I have the following in .rubocop.yml:

require: standard

inherit_gem:
  standard: config/base.yml
AllCops:
  TargetRubyVersion: 3.3.1
whysthatso commented 2 months ago

okay, so it seems to be user error: in the process of cleaning up extensions during migraiton to ruby-lsp, it turns out that possibly the manuelpuyol.erb-linter caused the errors, and for some reason i assumed they were attributed to standardrb.