Webpack-cli: [UI] Decide foundation of the project

Created on 16 Oct 2018  路  29Comments  路  Source: webpack/webpack-cli

Before starting implementing features, there's need to agree on the tools to use to build the UI tool.

We have to remember that this is a tool that will interact A LOT with the webpack-cli itself and some of the packages that we currently maintain. For instances, if we want to add a new loader, once the user decided which loader to add, we can run the command webpack-cli add or calling the method straightaway.

So there are two parts that to be developed, the server and the client.

Here's my 2cents:

  • Server: express
  • Frontend: create-react-app or if typescript, using babel for compilation. I don't trust the typescript compiler (and people are moving away from it)

About the styling of the site, I don't have particular inclination but usually I tend to choose solutions that are javascript-free (like bulma), but the I don't mind other choices.

For testing, we can stick with Jest.

Surely I have missed a lot, so feel free to add suggestions

Discussion UI 馃暥 inactive

Most helpful comment

@rishabh3112 has pretty much covered it with his GSoC proposal and he can answer you to your questions.

How the UI is going to be served.

It will be a SPA that will use sockets.

How much system res it will use?

What do you mean? It's not easy to quantify. If you'd use just to generate configurations, I'd say the sufficient amount to have a normal web server. If you'd use to use the watch mode, bundle analyser and more, it will depend by the size of the project. But will be a second step.

Exactly what core functionalities it's going to bring over the CLI.

Here.

Is it going to be served as a separate package or with the core cli?

Separate package

All 29 comments

I think at minimum req would be to use webpack dev server and that tool suite.

Agreed with @ev1stensberg. we should use webpack-dev-server. other point, I would like to follow with material-ui as our styling lib. since we're going in top of React, we get an lib that offer less work, providing the components, will reduce the amount of work.

For tests I would like to add enzyme too, so we could test our components.

About the tool itself, IMO, we should follow it as a CLI mirror, just reproducing the commands that we already have in CLI, based in that, our tasks could be:

  • [ ] Project Structure - Setup create-react-app, and generate our in final of this, we should have the create-react-app initial screen running.
  • [ ] Init - A screen, that will reproduce the same as webpack-cli init (same questions, etc).
  • [ ] Add - A screen, that will reproduce the same as webpack-cli add.
  • [ ] Info - A screen, that will reproduce the same as webpack-cli info.

I think we could have this as our v1/MVP of Webpack GUI. Am I missing something?

So, Are we starting off with JS first 馃?

I am not a big supporter of enzyme because it's too much dependent to the React versions. So there's the risk that can't upgrade React too frequently because enzyme might not support the new changes and can't keep up. Also the APIs are too wide. I am more keen to use the simple ReactDOM or react-testing-library.

@rishabh3112 It's up to you guys. Honestly, if you guys would like to start with TypeScript straightaway, just do it! We have knowledge of TS so I don't see the problem. I personally wouldn't start JS knowing there will be a migration to TS for the simple fact that the migration is really painful and time consuming. You all like TS? Let's go for it! You don't, JS is fine

I don't know TS, but if its in everyone's convenience I wouldn't mind learning it along in the way. But creating wouldn't creating UI in TS be a huge overkill considering we are using React anyway?

I think you misunderstand why we use TS. TS gets compiled down to JS anyway, just as JavaScript in ES6 needs to be compiled down

@ev1stensberg According to me, maintaining code in TS would be more difficult and more inaccessible to newer developers ( it was like that to me when I started out ). These are my opinions on TS although I could be grossly incorrect. In any case, I am comfortable with any tech stack we use ( I will become comfortable with the use of TS in a couple of days ). Also regarding my initial comment, I was suggesting not using TS along with React for simplifying the development process on the frontend side. Not being much experienced in TS, I don't have much idea about how many bugs will it help us prevent in their initial stages only or how will it simplify the architecture of the app, hence I wouldn't suggest against or for the use of TS and leave it to the other people in this thread.

I'd like to bootstrap a simple create-react-app project too. Easy, fast, reliable and it has the developer server under the hoods. No hassle, no configuration. We don't need that for the Frontend part.

Yeah, finally what I think is we can have express in TS and frontend in react i.e. JS.
If that's fine 馃憜 let me know !!

Ok. So looks like we agreed using create-react-app, right? About styling, can we go ahead with material-ui?

@rishabh3112 I don't like the idea to use TS and JS in the same project, mainly because I prefer follow an pattern and code in top of it.

Okay, @renatoagds,
Then let everything in JS.
So, lets conclude this disscussion 馃槂

I will rewrite the server in JS then 馃憤

@rishabh3112 Alright! That's great. Lemme know when the initial scaffolding is done so that we can start filling in the functions. In the meantime, It would be great if you could create an initial react scaffold too, so that I can work on the front end side of it.

@ematipico looked the issues that you created about UI, just want to know more about what you're think we should do on them.
https://github.com/webpack/webpack-cli/issues/648
https://github.com/webpack/webpack-cli/issues/649

@rishabh3112 It would be great if after the initial scaffolding of the project, we can distribute the task of creating the UI and the server amongst ourselves.

That's what we would be doing 馃槈.
Once the foundation is made we would most likely have a brainstorm. Mostly for api functionalities and frontend design of the GUI.

We can discuss which one to use now @ematipico @evenstensberg?

  • [x] preact
  • [ ] react
  • [ ] vue

It鈥檚 smaller and we are planning to integrate cli in preact

I can't get what you want to say here @evenstensberg

We should use preact because it is small and we are collaborating with their CLI

I don't mind any library, as far as the people are going to contribute it are willing to adopt it and have fun :)

no problem for me to go ahead with preact. if @evenstensberg prefer it, let's go.

Let's work on preact then !!

@ematipico @rishabh3112 are we going to follow the same path, and opening an PR with preact foundation?

@renatoagds Yes! Feel free to make a PR if you want. With preact cli it should quite quick to bootstrap a project

@ematipico @rishabh3112 cool!! I'll open the preact bootstrap

@ematipico @rishabh3112 opened the preact setup at #671 ... please, take a look

There are few things that must be addressed before getting started

  • What's the bundle budget
  • How the UI is going to be served.

    1. via a local server (by default React)



      1. or as a static site - pre-rendered/SSRed (using Gatsby)



  • Is it going to be served as a separate package or with the core cli?
  • Exactly what core functionalities it's going to bring over the CLI.
  • How much system res it will use?

I know a few things have already been discussed, but let's get the final verdict.

@rishabh3112 has pretty much covered it with his GSoC proposal and he can answer you to your questions.

How the UI is going to be served.

It will be a SPA that will use sockets.

How much system res it will use?

What do you mean? It's not easy to quantify. If you'd use just to generate configurations, I'd say the sufficient amount to have a normal web server. If you'd use to use the watch mode, bundle analyser and more, it will depend by the size of the project. But will be a second step.

Exactly what core functionalities it's going to bring over the CLI.

Here.

Is it going to be served as a separate package or with the core cli?

Separate package

Yeah, @ematipico answered precisely. As far as bundle budget is concerned, we are not aiming for that now. Instead, shiping features first with proper structure and guidelines first and then look for code splitting, etc for reducing size.

This issue had no activity for at least half a year.

It's subject to automatic issue closing if there is no activity in the next 15 days.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

snitin315 picture snitin315  路  5Comments

RobotnickIsrael picture RobotnickIsrael  路  5Comments

evenstensberg picture evenstensberg  路  5Comments

evenstensberg picture evenstensberg  路  5Comments

billyjanitsch picture billyjanitsch  路  3Comments