- remove `cargo-make` integration
- rework CI pipeline more granular and precise
- rework releasing process
- tune up project layout
- fill up new CHANGELOGs
Additionally:
- fix latest nightly/stable Rust inconsistencies
* Impl subscriptions for juniper_actix
* Add random_human example subscription
* Add actix_subscriptions example to CI
* fixup! Add random_human example subscription
* Migrate actix subscriptions to juniper_graphql_ws
* Simplify error handling
* Change unwrap to expect
* Close connection on server serialization error
Co-authored-by: Christian Legnitto <LegNeato@users.noreply.github.com>
* Implemented most test cases from the specification
* Unified error handling for all generators
- Removed proc-macro-error -> not required -> use syn::Error
- Everything below lib.rs uses proc_macro2::TokenStream
instead of proc_macro::TokenStream
- Replaced error handling in attribute parsers
* WIP better error messages for *all* macros
* Refactored GraphQLInputObject and minor tweaks
- removed support for Scalar within a string ("DefaultScalarValue")
- removed unraw function and replaced it with the built-in one
- added error messages and return types for all functions within utils
- added more constraints to fulfill the GraphQL spec
* Fixed test-cases which are not compliant with the specification
* Removed unused function
* Added constrains, updated error messages, added marker
* Added argument rename within impl_graphql and fixed `__` tests
* Formatted and cleanup
* Added GraphQLTypeAsync for input object
* Moved codegen tests to separate module
Nightly and stable produce different outputs, thus only test nightly.
* Added IsInputType/IsOutputType traits for type checking
Co-authored-by: Christian Legnitto <LegNeato@users.noreply.github.com>
* Use mdbook for building the book
* Update book config
* Update book hierarchy to work properly with mdbook
This necessitated adding place-holder index pages
since mdbook does not suppoert stand-alon menu items
* Update tests to use 2018 edition
* Fix various compilation errors in the tests
This isn't needed, as examples by default are built when the
containing crate is tested.
I also confirmed that `cargo run --example warp_server` still works.
Introduce an abstraction for scalar values
Before this change, possible scalar values were hard coded to be representable
by one of the following types: `i32`, `f64`, `String` or `bool`. This
restricts the types of custom scalar values that can be defined. For
example, it was not possible to define a scalar value that represents an
`i64` without mapping it to a string (which would be inefficient).
One solution to fix the example above would simply be to change the
internal representation to allow it to represent an `i64`, but this would
only fix the problem for one type (until someone wants to support
`i128` for example). Also this would make juniper not follow the
GraphQL standard closely.
This commit takes another approach, by making the exact "internal"
representation of scalar values swappable (in such a way that a downstream crate could provide its own representation tailored to their needs). This allows juniper to provide a default type that only
contains the types described in the standard whereas other crates could define custom scalars for their needs.
To accomplish this we need to change several things in the current implementation:
* Add some traits that abstract the behavior of such a scalar value representation
* Change `Value` and `InputValue` to have a scalar variant (with a
generic type) instead of hard coded variants for the standard
types. This implies adding a generic parameter to both enums that
needs to be added in the whole crate.
* Change the parser to allow deciding between different types of
scalar values. The problem is basically that the original parser
implementation had no way to know whether a parsed integer number is
a `i32` or a `i64` (for example). To fix this we added some knowledge
of the existing schema to the parser.
* Fix some macros and derives to follow the new behavior.
This commit also contains an unrelated change about the way `juniper_codegen`
resolves items from `juniper`. The `_internal` flag is removed and
the resolution is replaced by a macro.
The scalar parsing strategy is as follows:
* Pass optional type information all the way down in the parser. If a
field/type/… does note exist, just do not pass down the type
information.
* The lexer now distinguishes between several fundamental scalar types (`String`, `Float`, `Int`). It does not try to actually parse those values, instead it just annotates them that this is a floating point number, an integer number, or a string value, etc.
* If type information exists while parsing a scalar value, try the following:
1. Try parsing the value using that type information.
2. If that fails try parsing the value using the inferred type information from the lexer.
* If no type information exists, try parsing the scalar value using the inferred type from the lexer,
All macros support the introduced scalar value abstraction. It is now possible to specify if a certain implementation should be based on a specific scalar value representation or be generic about the exact representation. All macros now default to the `DefaultScalarValue` type provided by
`juniper` if no scalar value representation is specified. This is done with usability and backwards compatibility in mind.
Finally, we allow specifying the scalar value representations via an attribute
(`#[graphql(scalar = "Type")]`). A default generic implementation
is provided.
* Added juniper_iron crate
* Fixed up juniper_rocket crate
* Updated juniper/Cargo.toml
* Updated docs (readme, module docs)
* Export http integrator tests with export-test-schema feature
* Update CI tests (Use cargo-make )
* Format parts of the code base
This split still requires some work as the tests currently fail. This is
caused by the fact that some previously private modules can't be
accessed anymore, and that Rocket changet it's testing framework.
* `Url::into_generic_url` was deprecated in 0.4.1. The `Into` trait is
used instead.
* iron/logger removed support for ANSI terminal colors in 0.2.0, which
makes logging work in the Command Prompt on Windows.
Fixes#21
