Non-builder solutions

[ai]

I like your project. Honestly, I thought about something like it. Modern webdev is so hard to configurate, and you solve some problems.

But what do you think if we could solve more problem in one project:

• Run tests
• Run lint

Imagine if in future you could write webpack-blocks test and it will run tests in best practices.

Something like create-react-app, but modular in your way.

So, my question in short form: what do you think about handling other non-builder webdev processes like tests, linters, etc?

[andywer]

Hey @ai! Thanks :)

I was also thinking about something like webpack init to create a default webpack.config.js locally, do an npm install --save-dev and add build/start scripts to package.json.

Good news is that creating an eslint webpack block (using eslint-loader) is easy. When shipping it with some configurable defaults or when using one of the popular sets of linting rules then getting linting set-up would be a matter of one npm install and two lines of code in the webpack config file.

Maybe that's already a good solution.

Not sure about the tests, though. How would you think this should work / look like?

[ai]

I suggest to not focused on webpack, but try to cover webdev process.

When you want to add Jest. You add a Jest plugin into your tool config. Then when you will run webpack-blocks test it will execute all linters plugin and all test plugins.

Look at create-react-app. It is so popular, because it focused on entire build process. Developers doesn’t really care about webpack. Developers need a solutions. Webpack is just a part of this solution. But most of developers will be happy if they will be saved from knowing about webpack, jest, eslint. They want to have a solution for “prefixes”, “tests”, “lint”. This was a philosophy behind my project idea :).

[andywer]

Ok, I am getting the picture now ^^

Yes, true. A modular approach to application bootstrapping would make a lot of sense, especially to ease in from "just make it work, I don't care what it does" to "I need to customize some parts". Create-react-app hides the complexity nicely, but as soon as you feel the need to customize you hit the eject and suddenly you are in the middle of the infamous config mess.

Right now I would regard webpack-blocks as one thing and the new modular app bootstrapper as another independent thing that utilizes webpack-blocks besides other stuff.

I have no clear image in my mind yet how the modular app-bootstrapping stuff should exactly look like. Guess I need to sleep over it :) Maybe you have some more concrete ideas already?

Btw: Actually my focus this week would rather be on the https://github.com/flux-capacitor/flux-capacitor if the webpack-blocks wouldn't have caused so much positive feedback 😉

[ai]

Right now I would regard webpack-blocks as one thing and the new modular app bootstrapper as another independent thing that utilizes webpack-blocks besides other stuff.

Awesome! Please tweet about it ASAP :D

[ai]

I saw flux-capacitor. It was so strange, because I have very similar idea for other project ;).

But I already started this project, so in this field we will be opponents.

My projects is hosted on https://github.com/logux — sorry, there is some lack of docs and it will be hard to see full picture in current state.

But in short: Logux is a virtual syncable log for events between client and server. So it is very similar to flux-capacitor, but do it in different way. Anyway I think there will be space for both projects. Or you could take Logux to build flux-capacitor on top of it (Logux will be more low level).

[andywer]

Lol. Is that so? 😄

Interesting. Yeah, currently from the docs I couldn't have told much 😉

My approach is "let's create something nearly as powerful as CQRS, but as easy to use as any plain normal database". So our projects might still develop in different directions.

But tell me when it's easier to use :)

[andywer]

PS: I wrote some short tweets about the flux cap, but they were fairly basic. Will tell you when the next big step is done :)