Is there a recommended way to create consistent project boilerplates when working with modern JavaScript tools?
Currently for my work, new projects will require some combination of:
Webpack
Babel (ES Next)
ESLint
Typescript
Vue/React (framework)
Framework Router + Redux/Vuex Framework
Testing framework
These have taken some effort to become familiar with the configurations and get them working together.
Now, I have a git repo for each configuration that can be cloned for a project, like webpack-babel-eslint, webpack-babel-eslint-typescript, webpack-babel-eslint-typescript-vue, etc.
This solves the problem of initializing projects quickly, but requires making an adjustment to the webpack configuration (for example) in each repos configuration when a change happens, instead of adjusting the base webpack configuration in one location and having it be shared.
I've seen tools like Yeomon, but I very much sympathize with the feeling of it being 'yet another tool' in an already intimidating landscape. I've also seen the monorepo structure of Lerna look like it could be used to keep all of these repos isolated, but this makes sense to me more for traditional packages and not for boilerplate assets.
Is there a way to maintain our projects configurations in a robust, editable way that allows for quick prototyping, like the Create React App or the Vue-Cli?
Is there a recommended way to create consistent project boilerplates when working with modern JavaScript tools?
Yes There is a consistent boilerplate builder, it's called Yeoman, usually people use it to make projects consistent in their organisation, or in projects that have quite a lot of scaffolding use cases into them.
The problem with this, and something you addressed in the last part of your question, is the "one of" scaffoldings. When used in an open source community, the Scaffoldings need to serve a purpose and have visibility otherwise, they won't be just anything else but a grain in the desert.
Things like create-react-app vue cli or the angular cli are there and exist because they serve a very good purpose and also, because they have the support of the community and the visibility
So, if the scaffolding is for your work, or set of tools for your projects with friends, go ahead and use Yeoman, but keep in mind that, unless you are making new projects every other day, this will be more work than benefits.
If you are just doing it "for the community" don't even bother, CreateReactApp, angular/cli, and vue/cli are more than enough, unless there is a git issue with 1000 upvotes, and you will solve the issue by adding this tool
Related
I'm relatively comfortable with laravel, but know very very little about javascript and npm in general... just to set some context.
I am building an app where I now require a "library of forms" to be filled out. So I'm thinking that I should leverage the expertise of others, and take advantage of what appears to be quite an impressive bit of work, in the form of SurveyJS. https://surveyjs.io/Documentation/Library
I'm probably making a total dog's breakfast of these different concepts, so bear with me please.
So whilst I've got the npm thing running smoothly, I'm not sure I understand the whole webpack compilation thing (yet).
Can you explain to me...
My plan is to have a number of "surveys" defined suitably for the surveyjs "engine". The logic I'm seeing is laravel app eventually pulls "a survey" and passes it to a view to be "executed".
The surveyJs librarys will use that model amd provide the results back to the laravel app - I'll pickup the results in a controller and deal with them.
If this is a suitable approach, then what are these choices about? https://github.com/surveyjs
If I take https://github.com/surveyjs/surveyjs-php (because it's the closest thing I can find to php/laravel then first step is to install docker. I'm a little confused about why I would be installing more "infrastructure" when I'm actually looking for the libraries necessary.
I don't understand why what I'm thinking as a very clever bit of javascript seems to want it's own "infrastructure" - docker / webpacks / etc. And then there's still the whole laravel mix thing.
Thanks in advance.
The main repo has dists for several different js frameworks, the editor repo is just that - only the core surveyjs lib - and the other repos are sample apps, a base project template and extras you may not need.
JavaScript has become a whole ecosystem in and of itself: building with rollup, webpack, parcel, brunch, gulp? For which framework, if any, Angular, react, vue, jquery, vanilla or a little bit of a and a little of b? What are you targeting, browsers, node, both, making an electron app? Using es6? Newer? Typescript?
Basically you're seeing surveyjs want infrastructure because they have answered the above questions. Welcome to javascript :)
I think it has something to do with using webpack directly and therefore gives more flexibility. But I'm not completely sure if someone can explain what "ejecting" means. Also what are the ramifications of ejecting a create react app? Is it bad to do this, or?
To bootstrap a react project it will require for you to know about things like Webpack or Babel which might be a sticking point for people who do not want to learn about these.
create-react-app provides a fully configured environment with reasonable defaults (and possible to extend). Most infrastructure-related work is hidden from you, and whenever there are changes in one of the dependent packages this is taken care of for you -- it will only be required to update react-scripts.
I highly recommend this presentation by one of CRA authors it will give you a better idea of the project.
Now eject means that all of the configuration will be exposed to you. You will see every package which runs your project. Now you are responsible for maintaining all of that configuration.
This is not necessarily a bad thing; you are then left with more code to maintain, but you get full control in return.
Background
Starting on a new vue.js (2.0) project. I've worked with vue-cli in other projects (vuejs-templates/webpack) and found the build process difficult to grasp when doing any kind of changes.
On top of that, webpack is infamous for its lacking documentation, therefore it turned out to be a lot of work even to achieve minor tweaks to the build process.
In general, I believe I understand both webpack and vue-loader. I'm still having a hard time getting the full picture of vuejs-templates/webpack though.
Question
I'm considering rolling my own webpack config for this app, but I'm concerned I'll eventually end up with a build process as big as the current vuejs-templates/webpack.
My plan was to work my way up from vuejs-templates/webpack-simple and not overcomplicate things too much.
What I have in mind is a config / build process situated somewhere in between vuejs-templates/webpack-simple and vuejs-templates/webpack.
I'm interested to see how others (with perhaps more experience that I have) feel about vuejs-templates/webpack. Wonder if it will just get harder to use as the project grows or if it will all make sense eventually.
Does it make sense to roll my own webpack config / build process or should I just suck it up and use vuejs-templates/webpack?
After about a month of working with Vue, vue-cli & webpack, I figured out the following:
1. Roll-your-own boilerplate
This feels a lot like re-inventing the wheel. There's more than meets the eye: writing up all the config, loaders, picking a folder structure & setting up tests takes a considerable amount of time.
You'll be frequently shifting focus from developing your app to tweaking the build. There will be many small things you need as you develop, but the pain will be considerably reduced by using vue-loader from the start.
To sum up: this is a very big decision & you'll need to be ready to invest a considerable amount of time in it to be fully set up.
If your setup is so custom that you have to roll your own boilerplate, then be sure you'll have to redo a lot of the work that's been done already in templates/webpack. If you must, don't hesitate to get some inspiration from the current templates/webpack boiler, there are some neat tricks that you might want to use in your boiler. You could also start from the simpler webpack template and work your way up from there.
2. Fork templates/webpack
If you plan to redo some of the folder structure and perhaps change some of the core libs, it's a good idea to do your own fork of templates/webpack instead of starting from scratch.
It's not going to be easy at first, but as you begin to comprehend the structure & tools involved you'll realize the initial frustrations were well worth it.
As a bonus, you can install it through vue-cli and easily re-use it for other projects:
vue init username/repo my-project
3. Tweak templates/webpack
Sometimes you won't know in advance how your boilerplate will look like. In that case, I've realized it's fine to start with templates/webpack and do small changes along the way.
In that case, it's going to be hard to move it to it's own repo and install it via vue-cli. My recommendation is to take notes on whatever changes you do to the boilerplate (or add a #hash or smth to those commits).
That way, when you start your next project you can follow approach #2 and use it via vue-cli.
Conclusion
I think many of the issues you'll have with changing templates/webpack are also bound to pop up while doing it from scratch. It's probably because of Webpack's poor documentation (hey, Webpack 2 is looking better!) and the ridiculous amount of tools you need nowadays to build a JavaScript project.
Use templates/webpack and don't look back, the time you'll spent understanding it and vue-loader is waaay below the time you'll spend setting up your own boilerplate.
I'm currenlty doing the refactoring of an application and I want to follow the John Papa's guidelines as I found them very interesting and usefull in my case: John Papa Guidelines - Application Structure
So I arrive at the part where I decided to split my application into different modules corresponding to the features. Let's say one module for the accounts feature, one for the transfer feature and one for the user settings feature.
I can do it well according to the John Papa recommendations: one app module and three other modules (account-module.js, transfer-module.js and user-settings-module.js) and their corresponding navigation (states-config.js, etc.).
I hope I have been enough clear because now the tricky part comes :D
The idea I have is that I would like to build two (or more) different applications depending on what I want. I would like for example to build an application without the transfer module and doing this during my grunt process (by configuration).
Currently I am using the include_source grunt and grunt_war later on but there is no way to be more in an "angular module" context rather than using regular expression to specify which files I would like.
Those tasks don't allow us to say like "Okay, I would like to package this, this, and this module" for example (that would be fantastic!)
I think that big applications should have encountered this problematic as when they don't provide all business modules to every customer but make it configurable (at least I hope that's how they do).
The question is how? Do they do it? Is it manually (non sense), or do they have written some custom grunt (gulp) task or some custom scripts for this purpose?
Bonus question: Let's imagine we are living in a dream world and a grunt task exist for this. My next question will be, how to manage it within my application to configure my navigation for example (no more transfer button in the menu). I think that if the grunt task and the app use the same configuration file, that won't be a problem and I will be able to use grunt-angular-settings task to have a constant within my app.
Thanks for your attention and I'm very curious to read you :)
Regards, Yassine GAYL
interesting. take a look at how angular.js itself builds the artifacts. in src code, it has bunch of modules scattered in different folders. it introduces lib/grunt/utils and lib/grunt/plugins to handle the build process, say which modules should go into which destination file. you might have interests to try the same, good luck with it.
https://github.com/angular/angular.js/blob/master/Gruntfile.js#L166
Wanted to know if there is a good IDE with full support for Ember.JS not just basic JS. Or is there are any command line tooling or code generating tools like Grunt for Backbone.JS?
I have nothing for IDE with intellisense for EmberJS, but Sublime is usually the go-to program of choice for development in Javascript. With a few packages and a jslinter you can get cracking straight away.
In the editor, there are things called 'snippets' that allow you to type a key combination, and a large portion of the code will be instantly filled out for you. For instance this repo has a set that you can add to your Sublime application to help you get going. Apart from that, there's nothing really that can help you code faster and easier as having an automatic Jslinter (or jshinter depending on how much you hate Crockford) and a nice set of snippets.
With ember-rails you can generate an Ember.js app structure as well as controllers, models, etc. Find the generators here.
There is also a ember.js package for Bower. Have a look at Yeoman, which uses Bower for package management.