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.
Related
Background
NestJS comes with a feature called dynamic modules which gives the caller (=importer) of a module the chance to configure a module and thereby its providers.
Using dynamic module features, we can make our configuration module dynamic so that the consuming module can use an API to control how the configuration module is customized at the time it is imported.
(https://docs.nestjs.com/fundamentals/dynamic-modules)
Question
Does this flexibility come at any cost, meaning, are there any negative effects involved with this "dynamic modules" in the sense that it negatively impacts performance or the compilation result? Or is the only drawback of dynamic modules the little bit of extra code that is required to create them, in contrast to non-dynamic (=static) modules?
The only drawbacks that I have found with Dynamic Modules is that they can sometimes be a headache to debug if things go sideways during development. Otherwise, I haven't noticed anything changing in compilation or runtime.
I will say I am having a bit of a problem with configuring a dynamic module once and importing the then configured module without using a middle-man module to manage it, but otherwise they work great.
Edit 10/18/19
Wanted to come back and say that the issue I've been facing has been solved. It's a bit of an interesting solution, but I think overall it's a pretty cool one to see. Here is a high level context of it, hopefully there will be a blog post about it in the near future.
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
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.
We need to move a large application from silverlight over to html5.
The application will have a client and server part.
Because of the size of the application I thought it might be worth deviding some of the functionality into npm modules.
That way if I require to use it on the server side, i can and if I want to use it on the client (using aurelia) i can do that through jspm.
From a reusability of modularized js would you recon using npm being the best approach to maintain a versioned reusable stack or are there other ways of dealing with this?
Just want to do a sanity check to make sure I am on the right track.
Modularized code is definitely the way to go, I don't see any issue with using NPM as a versioned repo to deal with this especially as the code grows and is used by more and more people, however another approach might be using the githubs version tags, this might be a simpler solution as well (or atleast keeping everything in once place)
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