-
Notifications
You must be signed in to change notification settings - Fork 94
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
Non-builder solutions #1
Comments
Hey @ai! Thanks :) I was also thinking about something like 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 Maybe that's already a good solution. Not sure about the tests, though. How would you think this should work / look like? |
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 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 :). |
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 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 |
Awesome! Please tweet about it ASAP :D |
I saw 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). |
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 :) |
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 :) |
Updates to Webpack 4
andywer#1: Moving `TsConfigPathsPlugin` to resolve gets rid of `resolver.ensureHook is not a function` But leads to `Unexpected token` possibly because of JSX andywer#2: Resolved by `useBabel: true` andywer#3: Since I guess the point of webpack-blocks is reasonable defaults, I've included these nonessential options: - `useCache: true` with `cacheDirectory` set to node_modules, like `babel-loader` does (Why: https://github.com/s-panferov/awesome-typescript-loader#differences-between-ts-loader) - `babelCore: ...` I have babel bridge installed but maybe not everyone does (https://github.com/s-panferov/awesome-typescript-loader#babelcore-string-defaultundefined) - `babelOptions: ...` Sensible quality of life and bundle size reduction
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:
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?
The text was updated successfully, but these errors were encountered: