lamdera / lamdera/compiler

Migration generator uses new type name for old version when Union type is renamed

Open
#82 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Haskell
Stars
95
Forks
21
PR merge metrics
No merged PRs in 30d

Description

Bug Description

When a Union type is renamed between Evergreen versions (e.g. MoralType in V51 → CompanyType in V52), the migration generator produces a function with an incorrect type signature. It uses the new type name for the old version:

migrate_LegalEntity_CompanyType : Evergreen.V51.LegalEntity.CompanyType -> Evergreen.V52.LegalEntity.CompanyType

But CompanyType doesn't exist in V51 — it was called MoralType. The correct signature should be:

migrate_LegalEntity_CompanyType : Evergreen.V51.LegalEntity.MoralType -> Evergreen.V52.LegalEntity.CompanyType

This causes the generated migration file to fail to compile.

Root Cause

In extra/Lamdera/Evergreen/MigrationGenerator.hs:

  1. coreTypeMigration (line ~175) calls migrateUnionDefinition with typeName (the new name) instead of typeNameOld (the old name extracted from the pattern match)
  2. migrateUnionDefinition passes only the new type name through to migrateUnionDefinition_
  3. migrateUnionDefinition_ (line ~279) uses the same typeName for both the old and new type in the generated type signature

The Alias case (migrateAliasDefinition) already handles this correctly by accepting and using both typeNameOld and typeNameNew — the Union case was not doing the same.

Steps to Reproduce

  1. Have a Union type in version N (e.g. type MoralType = SCI | SAS | SARL)
  2. Rename it in version N+1 (e.g. type CompanyType = SCI | SAS | SARL)
  3. Run lamdera check to generate the migration file
  4. The generated migration file will have a type error because it references the non-existent new type name in the old version's module

Fix

PR #81 threads typeNameOld through migrateUnionDefinitionmigrateUnionDefinition_, following the same pattern as migrateAliasDefinition.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in extra/Lamdera/Evergreen/MigrationGenerator.hs at coreTypeMigration, migrateUnionDefinition, and migrateUnionDefinition_. Compare the Union path with migrateAliasDefinition and inspect PR #81. Done means a renamed Union generates distinct old and new type names in its signature and the resulting migration compiles.

Written by the indexing model from the issue text.

Assessment

Tech stack
elm, haskell
Domain
compilers, tooling
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.