Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(deps): update dependency dev.zacsweers.moshix:moshi-metadata-reflect to v0.17.2 #30

Merged
merged 1 commit into from
Jun 6, 2022

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Jun 5, 2022

Mend Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
dev.zacsweers.moshix:moshi-metadata-reflect 0.14.1 -> 0.17.2 age adoption passing confidence

Release Notes

ZacSweers/MoshiX

v0.17.2

Compare Source

2022-05-27

Fix: Fix IR lookups of setOf() overloads. There are two setOf() functions with one arg - one
is the vararg and the other is a shorthand for Collections.singleton(element). It's important we
pick the right one, otherwise we can accidentally send a vararg array into the singleton()
function.

Dependency updates:

Kotlin 1.6.21
kotlinpoet 1.11.0
kotlinx-metadata 0.4.2

v0.17.1

Compare Source

2022-03-09

Fix: Fix support for nested sealed types that don't use @JsonClass.

v0.17.0

Compare Source

2022-02-16

New: moshi-sealed now supports nested sealed subtypes!

In some cases, it's useful to have more than one level of sealed types that share the same label key.

sealed interface Response {
  data class Success(val value: String) : Response
  sealed interface Failure : Response {
   data class ErrorMap(val errors: List<String>) : Failure
   data class ErrorString(val error: String) : Failure
  }
}

moshi-sealed now supports this out of the box via @NestedSealed annotation. Simply indicate the nested type with this
annotation.

@&#8203;JsonClass(generateAdapter = true, generator = "sealed:type")
sealed interface Response {
  @&#8203;TypeLabel("success")
  @&#8203;JsonClass(generateAdapter = true)
  data class Success(val value: String) : Response

  @&#8203;NestedSealed
  sealed interface Failure : Response {
    @&#8203;TypeLabel("error_map")
    @&#8203;JsonClass(generateAdapter = true)
    data class ErrorMap(val errors: List<String>) : Failure

    @&#8203;TypeLabel("error_string")
    @&#8203;JsonClass(generateAdapter = true)
    data class ErrorString(val error: String) : Failure
  }
}

In this case, now Failure's subtypes will also participate in Response decoding based on the type label key.

Caveats:

  • @DefaultObject is only supported on direct subtypes.
  • If you want to look up a subtype rather than the root parent sealed type (i.e. moshi.adapter<Response.Failure>()),
    you must add the optional NestedSealed.Factory JsonAdapter.Factory to your Moshi instance for runtime lookup.
    val moshi = Moshi.Builder()
      .add(NestedSealed.Factory())
      .build()
Kapt is no longer supported by moshi-sealed

moshi-sealed has many implementations - kotlin-reflect, kotlinx-metadata, KSP, Java sealed classes, and
recently IR. These are a lot to maintain! To cut down on maintenance, Kapt is no longer supported and has been removed
in this release. Please consider migrating to KSP or Moshi-IR.

Fix: Properly report all originating files in KSP

With Kotlin 1.5.0, sealed types could now exist across multiple files. moshi-sealed's KSP support previously assumed
single files when reporting originating elements, and now properly reports all files if sealed types are spread
across multiple files.

v0.16.7

Compare Source

2022-02-01

moshi-ir

  • Fix: Use FilesSubpluginOption to fix build cache relocatability when generating proguard rules.

v0.16.6

Compare Source

2022-01-27

moshi-ir

  • Fix: Nested type argument use in properties would fail in 0.16.5's new type rendering. This is now fixed.
    Example failing case would've been something like this:
    @&#8203;JsonClass(generateAdapter = true)
    class Foo<T>(val value: List<T>)

v0.16.5

Compare Source

2022-01-20

  • Enhancement: Generate manual Type construction in moshi-ir adapter lookups. Prior to this, we generated IR
    code that leveraged typeOf(), but this appears to be too late to leverage compiler intrinsics support for it and
    appears to cause some issues if kotlin-reflect is on the classpath. This should improve runtime performance as a
    result.

v0.16.4

Compare Source

2022-01-13

  • Fix: Add moshi/moshi-sealed-runtime dependencies as implementation rather than api when applying the
    moshi-ir plugin. #​200
  • Fix: A second attempt at fixing extension point issues with AnalysisHandlerExtension in moshi-ir's proguard
    rule generation. #​201

Thanks to @​gpeal for contributing to this release!

v0.16.3

Compare Source

2022-01-11

  • Fix: Build new type parameters when generating classes in moshi-ir rather than incorrectly reuse the
    original class's parameters. Resolves this issue (that was
    originally believed to be a Compose issue).

v0.16.2

Compare Source

2022-01-06

  • Fix: Pass generateProguardRules Gradle plugin option correctly.
  • Fix: Best-effort avoid synchronization race with IntelliJ openapi when registering proguard rule gen extension

v0.16.1

Compare Source

2022-01-06

  • moshi-ir now supports dynamic generation of proguard rules, bringing it to feature parity with Moshi's existing
    code gen.
    • Note that if you have any issues, this can be disabled via the Gradle extension's generateProguardRules
      property and using the manual rules mentioned in version 0.16.0's notes.
      moshi {
        generateProguardRules.set(false)
      }
  • New: To help with debugging moshi-ir, a new debug property is available in the Gradle extension. It is off
    by default and can be enabled like below. Please try this out and include its output when reporting issues. Thanks!
    moshi {
      debug.set(true)
    }

v0.16.0

Compare Source

2021-12-24

New: moshi-ir

An experimental Kotlin IR implementation of Moshi code gen and moshi-sealed code gen.

The goal of this is to have functional parity with their native Kapt/KSP code gen analogues but run as a fully
embedded IR plugin.

Benefits

  • Significantly faster build times.
    • No extra Kapt or KSP tasks, no extra source files to compile. This runs directly in kotlinc and generates IR that is
      lowered directly into bytecode.
  • No reflection required at runtime to support default parameter values.
  • Feature parity with Moshi's native code gen.
  • More detailed error messages for unexpected null values and missing properties. Now all errors are accumulated and
    reported at the end, rather than failing eagerly with just the first one encountered.

Cons

  • No support for Proguard file generation for now #​193. You will
    need to add this manually to your rules if you use R8/Proguard.
    • One option is to use IR in debug builds and Kapt/KSP in release builds, the latter of which do still generate
      proguard rules.

v0.15.0

Compare Source

2021-12-10

  • Update to Moshi 1.13.0
  • Removed: The moshi-ksp artifact has been upstreamed to Moshi itself as is no longer published.
  • Removed: The moshi-records-reflect artifact has been upstreamed to Moshi itself as is no longer published.
  • Update to Kotlin 1.6.0
  • Update to KotlinPoet 1.10.2

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by Mend Renovate. View repository job log here.

@renovate renovate bot force-pushed the renovate/dev.zacsweers.moshix branch from 679943e to d4d5436 Compare June 6, 2022 06:19
@Yash-Garg Yash-Garg merged commit 0cfbfe2 into develop Jun 6, 2022
@renovate renovate bot deleted the renovate/dev.zacsweers.moshix branch June 6, 2022 06:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants