SaraVieira/fiddly

Reasonable defaults for other languages

hawkins opened this issue · 3 comments

You knocked #15 out of the park in record speed, so I thought I'd ask the follow-up question: Is it reasonable to include reasonable defaults for things like name, repository, etc for other package manger configs?

You support .fiddly.config.json for everything now which is 💯 and really all we need to support packages in arbitrary other programming languages, but you also can infer from package.json. What would you say to supporting other popular dependency manager files, such as Cargo.toml for rust, *.gemspec for ruby?

Immediate issue that comes to my mind is parsing these other formats. Because of that, I think it's totally reasonable in my mind to say this is out of scope, but at the same time it could really take that "no-config" ability of Fiddly to another level if you're open to it. 🤷‍♂️

Hey !

For toml files it's quite easy if I use something like: https://github.com/iarna/iarna-toml

I have no idea for *.gemspec files.

Do they have defined structure ?

I'm in for it. This is a great idea in my opinion

Is it this?

Gem::Specification.new do |s|
  s.name        = 'example'
  s.version     = '0.1.0'
  s.licenses    = ['MIT']
  s.summary     = "This is an example!"
  s.description = "Much longer explanation of the example!"
  s.authors     = ["Ruby Coder"]
  s.email       = 'rubycoder@example.com'
  s.files       = ["lib/example.rb"]
  s.homepage    = 'https://rubygems.org/gems/example'
  s.metadata    = { "source_code_uri" => "https://github.com/example/example" }
end

Yeah, that's the gem spec. I think that's actually technically just Ruby language, though, so not any kind of "Gemspec" language. Lots of them actually dynamically pull in ruby code above the Gem::Specification block (especially version), so this may be a minefield for Ruby.

But, we could at least try a basic ruby parser or hack job regex to try to find what can be statically inferred without reading ruby's require statements.

Or maybe that's too dicey and we cut Ruby out of first-class support for stability sake