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

CLI to efficiently scaffold Marble applications #109

Closed
edbzn opened this issue Mar 3, 2019 · 15 comments
Closed

CLI to efficiently scaffold Marble applications #109

edbzn opened this issue Mar 3, 2019 · 15 comments
Labels
proposal Middleware or feature proposal

Comments

@edbzn
Copy link
Contributor

edbzn commented Mar 3, 2019

Is your feature request related to a problem? Please describe.

Hello,

I noticed that Marble is inspired by the Angular ecosystem. In my everyday developer experience I really appreciate what the CLI tools bring to me. It helps to quickly scaffold main building blocks and enforce consistency.

It could be really nice to have CLI tools for Marble.

Describe the solution you'd like

The @angular/dev-kit and schematics can be a good fit to provide CLI functionality.

Describe alternatives you've considered

After digging in other CLI tools it appeared to me that there is no strong alternative to the @angular/dev-kit package.

@JozefFlakus JozefFlakus added the enhancement New feature or request label Mar 3, 2019
@JozefFlakus
Copy link
Member

JozefFlakus commented Mar 3, 2019

Hi @Edouardbozon,
Yup that a cool Idea! I've been thinking about this since the very beginning, but somehow I had to prioritize our next features and choose the most important ones. 😎

Regarding the @angular/dev-kit I have different feelings. I like Angular a lot, but I would like to use something dedicated. Maybe @krzysztof-miemiec have some thoughts about it? He likes building this kind of tooling 😄

BTW. Why do you think that Marble is inspired by Angular? I don't have such a feeling. 🤔 Can you elaborate it more? I'm interested in your thinking.

@krzysztof-miemiec
Copy link
Collaborator

Since I'm working on https://github.com/headline-1/alpha, which provides commands, I'd suggest using it as a simple base for CLI - supports types (io-ts) and generates docs out of the box.

@JozefFlakus JozefFlakus added proposal Middleware or feature proposal and removed enhancement New feature or request labels Apr 2, 2019
@edbzn
Copy link
Contributor Author

edbzn commented May 2, 2019

In a way Marble.js HttpEffect is the server-side equivalent to NgRx front-end Effect. They look similar in many points. I use NgRx schematics everyday to quickly scaffold effects. I think I can reuse some logic from NgRx schematics for Marble.js. I will give a try to this idea soon.

@karikalanarun
Copy link

Can I take this feature?. Now only I am starting to use marble js.

@JozefFlakus
Copy link
Member

If you want you can take it, right now nobody from the core team is working in this area. So far, I only think that it can be implemented outside the main repository 🤔

@karikalanarun
Copy link

Yeah, But it is inside marble js. Can I create a new repo or you will create it inside?.

@JozefFlakus
Copy link
Member

JozefFlakus commented Jul 11, 2019

The best would be if you'll start working on the POC directly from your public repository. It will be easier to validate ideas from this point. If the CLI will be ready then it can be transferred to @marblejs org repository.

@karikalanarun
Copy link

Okay. I will ideate through this, and get back here soon

@williamtetlow
Copy link

Could I suggest that development is staged into two tasks:

  1. cli for scaffolding new project
  2. cli for scaffolding components of project

Personally I think not having an efficient way to get started using a framework is the biggest blocker to adoption. One of my favourite things about react is how quickly I can get started using create-react-app. I know marblejs has an example repo but running npx create-marble-app is far easier and attractive to newcomers than pulling down the example project.

Especially if we can add customisation through arguments like --docker that adds docker support for both development and deployment.

Scaffolding project components is great but if the CLI only provides a mechanism for getting started quickly with nice defaults and suggested directory structure it adds definitive value by making the whole ecosystem more approachable.

@karikalanarun I'd be happy to help out if you need some?

@edbzn
Copy link
Contributor Author

edbzn commented Jul 19, 2019

I made a private repository a few months ago that uses @angular/dev-kit schematics to scaffold a Marble.js application with various options in one single command. It supports out of the box staging area that allows dry run and many other use full features.

I finally stopped because I went wrong. As you said @williamtetlow we need to split this in two tasks. I started by implementing the big task first: project scaffolding. But the right way to doing this with schematics is to create sub tasks first (like Effect scaffolding) and then scaffold the project by task composition.

I continue to think that schematics are the best way to scaffold an application. If someone is interested I can open the repository, but it really needs a re-write.

@karikalanarun
Copy link

Yes, I agreed @williamtetlow. But, what I thinking was, I need to split it up with routes first. I saw some best practices here. That will be helpful for us. we can create a project scaffold with marble.js with those best practices. Now, I am thinking to finalize that structure.

Good to hear from @Edouardbozon. can I see the repo?.

@edbzn
Copy link
Contributor Author

edbzn commented Jul 23, 2019

@karikalanarun I opened the repository. You can see there is a new schematic that scaffold an app based on the marble example project.

@JozefFlakus
Copy link
Member

Thanks for taking up this topic! Can't wait to see what will be the POC result of it.

Regarding the example project: The repo was created only for the DEMO purpose when the framework was on its early stage (v1.x). Since that time many things have changed in terms of features and possibilities that weren't available in version 1. I would recommend to not focus on this repo too much, especially in the file structure and coding conventions. I would propose to discuss the style guide and best practices separately so we can come to the common agreement in this area. 💪

@JozefFlakus
Copy link
Member

Closing due to inactivity.

@JozefFlakus
Copy link
Member

#386

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal Middleware or feature proposal
Projects
None yet
Development

No branches or pull requests

5 participants