‣

https://canary.warp-drive.io/guides/migrating/

Questions to answer:

• [ ] What is the goal structure that we can confidently communicate to users? The proposed structure would likely be used for the next decade
• [ ] How long can warp-drive support extensions?
  • [ ] Does a migration mean they are deprecated and people should handle data behaviors differently?

Considerations

• We should avoid using resources as a directory name as it might be confusing with ember-resources and warp-drive's own resource meaning.

Current codemod output structure

At this time the codemod spawns multiple files in different locations i.e.

     app/
     │   # old
     ├── models/
     │   └── user.js                    # Original EmberData model
     │   # new 
     └── data/
         ├── resources/
         │   ├── user.schema.js         # Schema definition
         │   └── user.schema.types.ts   # Typescript interface
         │
         └── extensions/
             └── user.js                # Extension: Behavior - methods, getters

The warp-drive documented structure

The original https://canary.warp-drive.io/guides/migrating/ examples mention such structure:

     app/
     └── data/
         ├── user/
         │   ├── schema.ts
         │   ├── type.ts
         │   └── ext.ts
         │   # Notice it's pure (no extension)
         ├── company/
         │   ├── schema.ts
         │   └── type.ts
         │
         ├── project/
         │   ├── schema.ts
         │   ├── type.ts
         │   └── ext.ts
         │   # Extension
         └── fileable/
              ├── schema.ts
              ├── type.ts
              └── ext.ts