I´m pretty new to gradle and currently there is question that bugs me. The situation appears as follows: Based on a bower technology stack I implemented an Angular App. The app as it is doesn't change nor has it to be built in any way since there are just static javascript and HTML pages. In my opinion the used versions of angular, bootstrap and other libraries should also stay the same due to compatibility of the single libraries so these files also shouldn't change. Is this a correct behavior or should I get at least the latest build of the used libraries version as I deploy the application?
Also less is used in the application. Is there a way to compile the CSS every time I run the gradle build file or should I deliver just the compiled and finished CSS file?
As a result I´m also not quite sure if it's recommended at all using gradle to deploy an "static" angular application.
I hope someone out there can help me to answer the questions above. As you can guess, I´m not very experienced at deploying of such angular applications since this is my first project with this kind of problem.
This goes for all package managers, not just gradle but npm, gem, nuget, maven, whatever.
Use static dependancy version numbers. Otherwise you will end up finding breaking dependencies in QA or Prod rather than production.
This means you need to be aware of security fixes in your dependencies.
When you need a feature or fix in a new version of your dependencies, unlock the versions, rebuild and test in dev. Re-lock the dependencies and send to QA for verification.
Related
I'm confused why all the React tutorials I'm using to learn React have me installing libraries through npm rather than importing through CDN's (React, Redux, Material UI, firebase, etc). I thought CDN's were more efficient.
Any guidance on this would be helpful (this is my first time using VS code and installing packages like this, the only other website I've programmed I just imported bootstrap and jquery through CDN and coded in notepad++ :/)
While you can of course use a CDN to import scripts into your application (with, for example a <script> tag) npm is useful in the fact that when you build your React app it will bundle all the required modules together.
This can be advantageous in the fact that your users don't have to download any scripts when your application loads (which can take some users with slower connections a long time) since everything is bundled within your React app. Some applications depend on a lot of dependencies, and forcing every new user to download each script individually can cause speed issues.
At the end of the day, I don't think there is a right or wrong answer as to whether you should use a CDN or NPM, just understand that when you use NPM it bundles the required scripts into your app when you run npm run build instead of the user having to download them when they visit your site.
CDN's will only get you so far. In the industry you're going to be expected to have some experience with npm/yarn. If you keeping going down the frontend rabbit hole, you'll eventually run into things like Webpack and Babble which will help make your Javascript a lot more efficient and backwards compatible. Installing things through npm/yarn will also often offer a lot in terms of providing you with a better development environment (things like react-scripts, eslint, prettier, etc).
In work we have a pretty complicated stack and situation, which could be somehow described as the following schema:
The situation is:
We have an old, poorly maintained PHP/AngularJs project which uses webpack for bundling.
We also have another project ("Some React Project") which contains a few sub-projects, and all of them are bundled into some bundle, which is then bundled with the old angularjs project. The AngularJs project then renders the React components from this bundle using some bridge library.
In addition, we have another modern React project, which is completely isolated and has it's own CI/CD process (it's actually another app).
Now we are going to develop a new module, using react, which should be used in all three projects.
We first thought about maintaining it by publishing it to NPM and for each update, to deploy it in any project using npm install. The problem is that it has SO MUCH OVERHEAD. It is so very hard to test and deploy. It's hard to maintain and since
some of our projects are very old, it's a complete nightmare.
Are there any other options available?
Is it possible to somehow deploy to package artifacts somehwere, and then automatically update it in all the projects?
Have you considered installing directly from another repo ?
Actually the overhead might be to have an auto-updated package. This would mean that you could never introduce a breaking change in that package.
{
"dependencies": {
...,
"common-package": "git+ssh://git#<your_forge_host>/path/to/<repo>.git#<your_tag_or_branch>",
...
},
...
}
Recently I started learning react and I saw a tutorial where they used Webpack to create the production and development builds. But there was no explanation on what the difference between those two builds is and which one you have to use when. I searched the internet but didn't find anything that helped me. Does anyone have a tutorial or an explanation that I missed/didn't read?
The development build is used - as the name suggests - for development reasons. You have Source Maps, debugging and often times hot reloading ability in those builds.
The production build, on the other hand, runs in production mode which means this is the code running on your client's machine. The production build runs uglify and builds your source files into one or multiple minimized files. It also extracts CSS and images and of course any other sources you're loading with Webpack. There's also no hot reloading included. Source Maps might be included as separate files depending on your webpack devtool settings.
What specifically separates production from development is dependent on your preferences and requirements, which means it pretty much depends on what you write in your Webpack configuration.
The webpack-production documentation is very straight-forward.
Also, the article Webpack 3 + React — Production build tips describes the process of creating production builds for React with Webpack pretty good.
The very basic difference is that Production Build has ugly, minified(compressed) version of your javascript code, so this makes rendering of file on end user's browser very quick and performance enhancing.
You can also verify if production build is being used in the website by applying a google plugin extension, which when activated on your browser, will always tell you if the website is using react js on the front end and also tells whether the build type is production or development.
when react is development build,
production-ready versions of React and React DOM as single files are available as well,
<script src="https://unpkg.com/react#16/umd/react.production.min.js"></script>
<script src="https://unpkg.com/react-dom#16/umd/react-dom.production.min.js"></script>
NOTE: Remember that only React files ending with .production.min.js are suitable for production.
The production and development build come into the picture just because of performance impact in real life deployed the application. Also, it happens that the location where the application is deployed is another continent altogether, so rendering development build js files on UI will take a hell of a time as compared to production version which is very crisp, compact, compressed, uglified for better user experience and loading on UI. for information CLICK HERE
react.development.js provides us extra features like debugging, hmr(Hot module reloading) and lots of other stuffs that you might
use while developing app with the help of bundlers like webpack, parcel, vite. This bundler bundles and minifies our code to be
deployed on production
These minified files will be deployed on production which removes lots of unnecessary files which will not be used by our app
for this we have react.production.js to make our much faster(as bundlers and lots of other files have done there work and are not required now)
Recently I've been running into an issue and I'm not sure how to best resolve it. We have a very modular architecture on the front end. We write individual angular components, put them in different repo's, and then include them in other apps as they are required, built with webpack & included via NPM.
Recently I've run into issues where multiple versions of a module end up in the compiled /dist folder coming from different places such as:
Directly included in the App I'm working on
2x Indirectly included through a module that I included (see chart for details).
The reason different versions could be used is that at the time CodeA is written ModuleA may be at version 1, then at a later date CodeB is written which also uses ModuleA which is now at version 2.
Then CodeA and CodeB are included in CodeC and now you have a module name collision on ModuleA.
With this setup, I believe if the multiple modules by the same name are loaded, the last one to get loaded is going to be the code behind that module name. Meaning it will be the one to be used by all modules. So there's no guarantee that the most up-to-date version is will be used. This usually results in getting an error that a method on ModuleA by name XXX does not exist.
To make sure I'm running the latest version of the module I have to go in and manually update (npm install) and build with webpack (npm run build) each library and then push them all to Github. Then I have to npm install in my root app. This isn't always an easy thing to do as the individual libraries' code may need updated to use the latest version of the module in question.
I'm looking for a solution to this issue. I'm guessing a structural/organizational change that will help us to not get into this predicament. If you have any solutions/advice/articles I need to check out please share. Thanks!
I'm trying to set up a client-side app workflow with yeoman (http://yeoman.io/), and as I'm coming from Rails background, I'm used to the niceties of the asset pipeline, which is backed by Sprockets (https://github.com/sstephenson/sprockets).
I'm struggling to make all the parts play nice with each other, and already spent a few hours trying to figure it out.
The first question that comes to mind is, is there a well established (e.g. convention over configuration, like in Rails world) way of developing a client side application with yeoman? Some definitive guide (besides the basic webapp-generator guide), perhaps?
Some suggest using requirejs (which I rather not use, because while it simplifies things in development, I'll need to jump through hoops to package the app (e.g. use Almond.js or AMDclean.js, or incur the unneeded overhead of requirejs).
My setup is:
Coffeescript, Backbone + Marionette, Handlebars for templates and ZURB Foundation with SASS.
What I'd like to accomplish in the end is the following setup, while using bower for managing the 3rd party dependencies:
In development:
Have something like Rails' manifest for javascript, so I can declare the order of dependencies, which will exploded into the the index.html
For all .scss files a .css entry added to index.html
Each file watched and compiled when needed
In production (dist):
All .scss files compiled, minified and concatenated to app.css
All bower files concatenated and minified to vendor.js
All application coffeescript files compiled, minified and concatenated to app.js
All templates compiled, minified and and concatenated to templates.js
index.html modified to include only those four files.
Is there something like this setup available?
I'm also open for suggestions and/or other alternative workflows.
Yeomam won't get you as close to a Rails workflow as you might expect. My two cents is that you take a look at something like Middleman has it does what you want out of the box.
Yeoman way
Using generators
You can use Yeoman generators and try to find out the combination of generators that will better suit the stack you are looking for, from what you describe I might take a look at:
webapp
backbone
maryo
At this point most of your requirements (both development and production) would be fulfilled:
a well defined project structure
compile coffeeScript and .scss
watch and compile
generators for model, view, collection, ...
compile and minify all files for production
You can use multiple generators to customise your own stack, every time that Yeoman detects that a generator overwrites a existing file it will prompt what to do, and you should be able to manage the conflict by yourself. Some framework-generators will obviously clash (it wouldn't make sense to try to use a angular generator on top of backbone).
Fine tuning
You can use sub-generators to scaffold more specific parts of your app, see Addy Osmani video.
Building generators
If you feel limited by some of the choices that a generator might impose (e.g. you prefer browserify instead of requirejs) you might want to fork a generator and add that as an option. You can even build a generator form scratch that will build your custom stack!
Grunt and Bower way
Yeoman is build on top of this two, but you can opt out at any moment and build your own stack using this two. You can add your dependencies through bower, and your tasks using grunt. There are plenty of examples that can give you some guidance, you could start with Yeoman webapp. There are also good examples at github like juanghurtado/puppeteer.
There are 3 files that you must keep an eye:
package.json — all you node dependencies go in here
bower.json — to manage the client dependencies
Gruntfile.js — here you define the tasks
Wrapping up
Maybe I'm stating the obvious but Yeoman does some magic work and helps you managing Grunt and bower, this magic only happens when you fully understand how this 2 work. So I would recommend that first you dive into some code and fully understand how Grunt and Bower work, and then you may use Yeoman magic.
Some other tools
You asked for some suggestions, here it goes:
gulp.js An alternative to Grunt. More you dive into Grunt more you will want Gulp (IMHO).
browserify An alternative to Requiere. Read this
assemble Static site generator for Node.js, Grunt.js, and Yeoman
Roman,
Answer for your first question, here is a guide on how to use Yeoman: http://code.tutsplus.com/tutorials/building-apps-with-the-yeoman-workflow--net-33254
If you want to use coffeescript by default, just pass the --coffee param
yo webapp --coffee
handling the assets order you can handle from the index.html file.
When you want to get the app ready for production just type the
grunt build
that will unify and minify all of your assets and throw it all dist folder.
To customise what you have in the build process you would have to write your own or customise the grunt build task, so that it will do exactly what you want.
Hope i gave you some useful information :)
Not an answer to my original question, but rather a pointer for someone who'd like to implement the same workflow I was looking for. I ended up writing a custom Gruntfile, using the grunt-injector to do the "explode the assets to the index.html" part, grunt-bower-install to add bower assets and configuring the grunt-usemin, grunt-contrib-concat, grunt-contrib-cssmin and grunt-contrib-uglify accordingly.