🦋 Changeset detected

Latest commit: 728224eef0fa3e63e89c98ab2279ac14310a107b

The changes in this PR will be included in the next version bump.

<details><summary>This PR includes changesets to release 6 packages</summary>

</details>

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@sketch-hq/[email protected]

Minor Changes

• d034e3b: Change rule config merge behaviour. Instead of overwriting the entire rule config, options are overwritten individually.

@sketch-hq/[email protected]

Patch Changes

• Updated dependencies [d034e3b]
  • @sketch-hq/[email protected]

Resolves #188

Currently, extending an Assistant will merge any new Assistant configuration with the configuration provided by the base Assistant. However, any existing rule configs are replaced, not merged, by newly provided rule configs.

Given an original configuration such as:

{
  rules: {
    'rule-1': {
      active: true,
    },
    'rule-2': {
      active: true,
      foo: 1,
    },
    'rule-3': {
      active: true,
      bar: "hello",
      baz: "world",
    },
  }
}

… extending the Assistant with the following config:

{
  rules: {
    'rule-1': {
      active: false,
    },
    'rule-3': {
      active: true,
      baz: "everyone",
    },
}

… will result in:

{
  rules: {
    'rule-2': {
      active: true,
      foo: 1,
    },
    'rule-3': {
      active: true,
      baz: "world",
    },
  }
}

This configuration is invalid because rule-3 does not include all required properties with bar missing. One option is to always provide a full configuration for each rule but this seems inconsistent given that the Assistant configuration overall can be partial.

Instead of shallow merging rules, it would be better to deep merge them as it makes it easier to tweak existing Assistants.

Is it feasible to avoid any here? Could maybe use Record?

Record<string, RuleConfigOption>

or similar?

Right, indeed … I omitted the one with the active: false. Your version is the desired one.

🦋 Changeset detected

Latest commit: 30f7bfc20d0e3c5858ff99f633bae5eb09c1c334

The changes in this PR will be included in the next version bump.

<details><summary>This PR includes changesets to release 2 packages</summary>

</details>

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Resolves #188

I think your final code block above should be

{
  rules: {
    'rule-1': {
      active: false,
    },
    'rule-2': {
      active: true,
      foo: 1,
    },
    'rule-3': {
      active: true,
      baz: "everyone",
    },
  }
}

Currently, extending an Assistant will merge any new Assistant configuration with the configuration provided by the base Assistant. However, any existing rule configs are replaced, not merged, by newly provided rule configs.

Given an original configuration such as:

{
  rules: {
    'rule-1': {
      active: true,
    },
    'rule-2': {
      active: true,
      foo: 1,
    },
    'rule-3': {
      active: true,
      bar: "hello",
      baz: "world",
    },
  }
}

… extending the Assistant with the following config:

{
  rules: {
    'rule-1': {
      active: false,
    },
    'rule-3': {
      active: true,
      baz: "everyone",
    },
}

… will result in:

{
  rules: {
    'rule-2': {
      active: true,
      foo: 1,
    },
    'rule-3': {
      active: true,
      baz: "world",
    },
  }
}

This configuration is invalid because rule-3 does not include all required properties with bar missing. One option is to always provide a full configuration for each rule but this seems inconsistent given that the Assistant configuration overall can be partial.

Instead of shallow merging rules, it would be better to deep merge them as it makes it easier to tweak existing Assistants.

:green_heart: :blue_heart: :purple_heart: :yellow_heart: :heart:

The mappings/2 function returns the enum values and their respective mappings in a keyword list.

Ah right, thanks! I tried it but I'm still getting an exception from Ecto.Repo.Queryable.load!/5 first. I'll continue checking...

Sounds good to me. While dump_values doesn't seem like the most useful function, I think having it and values combined gives us enough consistency without sacrificing ergonomics. Will address that

Another option is to have values, dump_values, and mappings. So we extend the existing API with two types of values for clarity?

Added a commit with the deprecation. I'm not really a fan of it it because I find Ecto.Enum.values/2 to be really ergonomic.