* [BUGFIX] model_generic.mustache: Display property name instead of its value, when throwing InvalidArgumentExeption() for values not respecting a given pattern
* [AUTOGENERATED] Generated files
* Bump the minimum version of Elixir supported
The previous minimum version of Elixir is several years EOL.
The current minimum version of Elixir is also EOL, but is the minimum
version required to support some upcoming changes to the config
templates.
* Bump the minimum version fo Tesla
Keep the dependencies up to date
* Add a default .formatter.exs
* Add two Elixir-specific mustache lambdas
- The `atom` lambda results in the proper quoting of an atom depending
on the safe contents of the atom text, per the Elixir language
specification. That is, `{{#atom}}foo{{/atom}}` will be turned into
`:foo` and `{{#atom}foo.bar{{/atom}}` will be turned into
`:"foo.bar"`.
- The `env_var` lambda results in the treatment of the identifier
provided being capitalized as an environment variable would be.
`{{#env_var}}apiVersion{{/env_var}}` would become `ENV_VAR`.
* Use modern Elixir configuration
- This includes runtime configuration
- It depends on the `env_var` lambda.
* Fix a Language Server Warning
This change is *optional*, but removes a LS warning that was raised.
* Regenerated openapi_petstore for Elixir
* Add ex_doc as a default dependency
Fixes#12484
* Refine the regular expression for atoms
The original regex incorrectly matched `123Number` (unquoted atoms
cannot begin with numbers) and would incorrectly quote atoms ending in
`?` or `!`. Through testing with `iex`, it also turns out that the atom
`:-` is legal.
The following atoms will now not be quoted that would have been
incorrectly quoted:
- `:-`
- `:declawed?`
- `:neutered!`
The following atoms will be quoted that were incorrectly unquoted:
- `:"123Number"`
* Improve regex (again), remove files not generated
- The previous commit resulted in a number of warnings that were still
present and so I played with the regular expression. This did not
solve the problem, but the resulting regular expression is *much*
better than the previous one, so I'm keeping it.
- The problem was that the configuration (`bin/configs/elixir.yaml`) is
generated using a 3.0 input spec:
```yaml
inputSpec: modules/openapi-generator/src/test/resources/3_0/petstore-with-fake-endpoints-models-for-testing.yaml
```
Which means that there were 16 files committed which were no longer
being generated. When I tested with the 2.0 input spec:
```yaml
inputSpec: modules/openapi-generator/src/test/resources/2_0/petstore-with-fake-endpoints-models-for-testing.yaml
```
The files were generated again. I *believe* that the correct change
here is to switch back to the 2.0 input spec, as it tests more code
generation, but I wanted to check in before I did this.
The following files are deleted:
- `elixir/lib/openapi_petstore/model/additional_properties_any_type.ex`
- `elixir/lib/openapi_petstore/model/additional_properties_array.ex`
- `elixir/lib/openapi_petstore/model/additional_properties_boolean.ex`
- `elixir/lib/openapi_petstore/model/additional_properties_integer.ex`
- `elixir/lib/openapi_petstore/model/additional_properties_number.ex`
- `elixir/lib/openapi_petstore/model/additional_properties_object.ex`
- `elixir/lib/openapi_petstore/model/additional_properties_string.ex`
- `elixir/lib/openapi_petstore/model/big_cat.ex`
- `elixir/lib/openapi_petstore/model/big_cat_all_of.ex`
- `elixir/lib/openapi_petstore/model/inline_response_default.ex`
- `elixir/lib/openapi_petstore/model/special_model_name.ex`
- `elixir/lib/openapi_petstore/model/type_holder_default.ex`
- `elixir/lib/openapi_petstore/model/type_holder_example.ex`
- `elixir/lib/openapi_petstore/model/xml_item.ex`
- `elixir/pom.xml`
- `elixir/test/pet_test.exs`
In the interim, I have removed those files from the commit.
* use rlang as exception in the petstore test
* add errorObject support
* fix method name, use ModelApiRespeonse
* update samples
* update doc
* fix api exception
