Roadmap

[Nathan-Schwartz]

I really love this project and I would like to contribute more. One thing that I think could make the contribution process easier would be sharing some sort of roadmap. It is a little tricky to determine what needs to be done and what the current priorities are based on what is available in the repo.

Here are some the questions I have had so far:

• There is currently a pult add command, has there been any discussion around a pult remove command?
• If a user wants to install pult module mithril, but is missing pult module spa, should they be provided the option to install both at the same time?
• Currently this project doesn't have tests for commands, modules, or generators. Are test suites desired? If so, is there a preferred test runner or assertion library?
• What is the level of interest in adding project typings? (Flow / Typescript)
• Are there any modules on the "wishlist"?
  • GraphQL
  • AngularJS
  • Vue.js
  • Elm
  • Support for no-SQL databases

Thanks! 🙂

[gilbert]

Hi Nathan, great questions! Here are some quick answers:

• Yes, I think providing the option to install module dependencies is a good feature to have. I would be careful about implementing it by trying to not complicate the codebase too much, since it's a nice-to-have rather than an essential feature.
• Tests would be great! There aren't any only because I haven't looked into how to test generated files cleanly. e.g. you have to see if the server starts, if an endpoint exists, etc.
• I'm not opposed to other tech, so long as they follow the principles outlined in the readme, and the code structure comes from a proven project (all modules in pult are extracted from real codebases).

Long answer to the roadmap: I've been meaning to explore a project structure that uses TypeScript or Flow on both the frontend and backend to increase productivity and maintainability. My ideas around it are:

• Single, type-checked model definitions for frontend and backend (e.g. a User interface)
• Queries results from server having inferred types (e.g. GET /users/4 automatically being typed as a User interface)
  • Maybe GraphQL will help in this area?
• Somehow, someway, auto-validate data based on type interfaces or model definitions (e.g. User.validate(obj))

Basically, I'm interested in having a single model definition, and from that generate as much as you can from it. I'm not sure exactly what it will look like, but these are the rough goals in mind :)

[Nathan-Schwartz]

@mindeavor Thanks for the response!

Testing seems like it will be really involved. I was brainstorming a little earlier and I think we could utilize Jest snapshots for testing the generated files and the content that is served. I might give it a shot and see how it works.

I really like the idea of sharing model definitions between frontend and backend 👍

runtime-types (or something like it) could be a good solution to validating data at run-time using flow types.

Do you have any thoughts on a pult remove command?

[gilbert]

runtime-types looks interesting, thanks for the link :)

Because pult modifies files, pult remove would be difficult to do 100%. But I think it would be useful to have pult remove remove generated files, since they would not have been checked into git yet, and removing them manually can be annoying.