digineo / xrechnung

Xrechnung

Welcome to your new gem! In this directory, you'll find the files you need to be able to package up your Ruby library into a gem. Put your Ruby code in the file lib/xrechnung. To experiment with that code, run bin/console for an interactive prompt.

TODO: Delete this and the text above, and describe your gem

Installation

Add this line to your application's Gemfile:

gem 'xrechnung'

And then execute:

$ bundle install

Or install it yourself as:

$ gem install xrechnung

Usage

TODO: Write usage instructions here

Development

After checking out the repo, run bin/setup to install dependencies. Then, run rake spec to run the tests. You can also run bin/console for an interactive prompt that will allow you to experiment.

To install this gem onto your local machine, run bundle exec rake install. To release a new version, update the version number in version.rb, and then run bundle exec rake release, which will create a git tag for the version, push git commits and tags, and push the .gem file to rubygems.org.

Contributing

Bug reports and pull requests are welcome on GitHub at https://github.com/digineo/xrechnung. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the code of conduct.

License

The gem is available as open source under the terms of the MIT License.

Code of Conduct

Everyone interacting in the Xrechnung project's codebases, issue trackers, chat rooms and mailing lists is expected to follow the code of conduct.

xrechnung's Issues

Canonical fork / gem maintenance

Hi! First of all, thank you for this gem. It's definitely saving me a lot of work :)

I noticed that there are various forks such as this one which added a number of new XML-tags (which I also need). But there was no concerted merging back into your original code, not to mention the gem on RubyGems.

I wanted to ask if you're generally open to pull requests if they are in an ordered manner? Would you then be willing to push the changes to RubyGems on a regular basis? Maybe something like in this manner where I backported the changes (and fixed the specs).

Also, if I understand it correctly, the validator is only used to test some fixtures. It would be great if the code in the test suite could generate various complete xRechnung documents (a minimal one, one with all possible tags, one with some optional tags) and then have the validator check all the generated code. This way, the test suite would actually catch XML files which this gem generated but are invalid. I have a proof-of-concept for that

I'd be grateful for your thoughts and thank you for your time. Let me maybe also ping @florian2 into the boat for feedback.

PS: How important is it for you to remain on Ruby 2.7 (which is end of life)?

PPS: You have a heavily customized Rubocop file. In my experience, open source collaboration is greatly improved when the linter is as close to the convention as possible. Are you open to getting closer towards standard Rubocop?

PPPS: I'm not sure about the # noinspection RubyResolve comments, since I'm not using IntelliJ. I take it, the YARD @!attribute comments are auto-generated? The "noinspection" shows up in the documentation at any rate.

Global state using `MemberContainer`

I noticed that this test fails, because the MemberContainer has a global state somehow. It even persists across Rails requests.

doc1 = ::Xrechnung::Document.new
doc2 = ::Xrechnung::Document.new

doc1.invoice_lines << Xrechnung::InvoiceLine.new

expect(doc2.invoice_lines).to be_empty # Fails - doc1 and doc2 have the same invoice lines

Are you aware of this? Could MemberContainer be replaced with a thread-safe gem, such as dry-initializer?

PS: Maybe something like Shale would be easier in general?