Seeking some ideas on how to better improve my teams local development workflow...
We have a Vue CLI shell application project that runs locally via node. Then we have a number of small Vue CLI web-component applications that served up via node.
When the shell is ran it reaches out to each web-component application retrieving a manifest.json file which tells the shell where/when to display the respective web-components.
Our web-component applications are built using something like...
vue-cli-service build --target wc --name foo 'src/components/*.vue'
Having to continuously build the web-component projects after making a code change... debug... and then rebuild again seems cumbersome. This is a new application so at the moment the codebase is in constant flux.
Was hoping someone may have suggestions on how or tools we might use to increase our productivity.
Don't overcomplicate things.
Here's Nuxt.js
As far as I can tell it does everything you want to do straight out of the box. Just set up a basic hello world project with Nuxt and see if it does everything you need it to do for you. It uses Vue.js and Webpack to build the exact same type of application you'd be developing otherwise with Vue, it just has a nicer layout and easier workflow in general. It supports hot reloading on file changes, you'd just run nuxt in the root folder of your project and a local server is started that hot reloads your project whenever you save changes to a file. You then distribute it either as a static application with nuxt generate or build it as a server side rendered application using nuxt build and nuxt start.
Related
I have a node.js application that run as a application server.
It is deployed on an Ubuntu 20.04 machine running on AWS, uses nginx as a reverse proxy and PM2 as a service starter.
Everything seems perfectly configured.
What looks strange to me, is that I have a React application, in a similar environment, but, before to move it on the server, I run build it, so creating a sort of packed and not easily human readable application.
My question is: Is there the need to do the same with a node.js application?
And, in case of positive answer, How to 'build' a node.js application?
There is no need to build a normal nodejs application.
What you mean is the use of a bundler e.g. webpack and a javascript compiler e.g. babel. To create a react application, you usually use a tool like create-react-app that sets up all this stuff for you. For react you need the compilation beacause you use the jsx syntax that browsers do not understand. In addition to that a bundler has some more advantages.
Check out this video if you want to know more about it:
https://www.youtube.com/watch?v=5IG4UmULyoA
No you don't have to build anything for node.js you just have to run the server. for client side apps you need to build and serve the Dist through web servers like apache or nginx.
I've built both Node.js servers, and React apps before, but I'm working on a project that requires some deployment scripting for the first time.
Specifically, I'd like to be able to have a script download a file locally and generate some json before my CRA React + Typescript build happens, in order to automate some functionality.
More generally though, I'm wondering what the best practice is for creating an arbitrary script (ideally in Typescript!) that can be run as a part of the build pipeline for a React app.
I assume this would be a node or node-ts script of some sort, but I can't figure out how to slot it into the project structure!
Bonus points if WebStorm will still be able to resolve any import/requires :)
Thanks!
I'm building a small project using Angular 7. When you run
ng serve
and a NodeJS server is spun up to handle requests, does each request block until processing is complete? We are trying to evaluate how effective using this in production would be as opposed to using a more traditional application server.
Run build --prod to generate a "./dist" folder.
Then you have to put that on a web server.
You can use Angular Server Side Rendering (SSR) to run it on a node.js server.
You should not use ng serve for production because it use webpack-dev-server that is build for development only.
Github link
ng serve runs a webpack development server behind the hood.
a development server.
It's made to mimic the production build and see your final application in an esay way.
If you didn't have that command, you would need to run a command like simplehttpserver after rebuilding all of your application on every change.
This is a convenience tool provided by the CLI to ease your development, in no case it's suited for production mode. This is a server without security, without optimization, without performance, without ... Well, without anything that makes a server, a server. By default, it deosn't even make your application accessible outside of your localhost. Not so useful for a production mode ...
So, never, I repeat, never, use this command for your production server.
Run ng build --prod
It will generate minification code in "dist" folder. you have to upload the file content of this "dist" folder. It will give faster response for loading web pages.
For more details please refer Angular deployment guide
When using ng serve, you are spawning a backend nodejs environment with a web server to handle requests towards your angular application. That's great for reloading and quick startup when developing. But needing such resources for static pages is unnecessary.
At the end of the day Angular is just a framework telling you its opinion on how to build an SPA. No matter the framework or library you use, you will always end up with an index.xxx, Javascript files and other resource files from vendors or internally. Only these matters to the browser loading the webpage.
Hence, you need to build your app to generate the static files that will be served (i.e. ng build --prod). Then you have 2 good options:
Choose a web server that will serve the files (i.e. nginx) on a dedicated server (or even container).
Place the files behind a CDN provider. Since they are static, they will be cached and served to a browser requesting them based on its location.
I would opt for #2 as opposed to #1 forcing you to keep running resources (CPU, RAM, HDD) for files that will be requested not that often. I say not often because your SPA will be handling all routes within itself in the client's browser (and minimum once a day will request a cache refresh).
Quick background: I'm a java web developer. I deploy my apps in EARs. I'm not familiar with how the build process works for the new JS frameworks like ReactJS. I have been using WebPack as a build tool but only in dev. I'm trying to keep up with the growing tech because my company is slowly adapting to it.
Question 1
How does the build process work when deploying a React app to a prod app server (or any server at that)?
I'm guessing Node will have to be installed on the app server with WebPack as a globally installed package so when the app is ready to be built, WebPack will kick off its build script in the package.json file that will create your bundle.
Question 2
If the above ^^ is somewhat correct, how do you kick off the WebPack build script?
My company uses IBM's Rational Team Concert as version control. RTC uses Ant scripts as their build so I'm guessing since we have a Spring Boot API that uses Gradle, we can tell the Ant script in RTC to run the Gradle script so the Spring API will build. Right before the Gradle build ends, Gradle can kick off the WebPack build script that will create the bundle.js. And from there you should have a full functioning frontend service just like you would when developing it.
This whole process has a been a headache to wrap my mind around and would like to get some clarification because there's only so much I can research without pulling all of my hair out. I hope I'm somewhat close to the correct way this process works.
In new version webpack (>=4) added new options mode for set environment. For get more information read this tutorial
webpack conf for production
and about deploy (ci,cd), webpack required before build, after build you don't need any js tools (SSR other case). Just create archive (project_${branch_name}.zip) and upload some store like gitlab, awsS3, etc and download when deploy.
I'm recommend don't mixing ui with backend if it possible split project other repository.
Note that RTC has multiple build definition templates. ANT is just one of them. You can also use the Maven build template, the Command Line as well if using the Jazz build engine. If its connected to Hudson/Jenkins for its build functions, you can use those as well.
I'm working on a web application that currently uses vuejs for part of its interface. The back-end is NOT in Node, so there is currently no package.json file or any tool from the typical npm stack in this repository.
We already have a bunch of non-npm dependencies that need to be installed in order to use the repository, so my coworkers aren't too open about the idea of adding another layer of complexity. I can't blame them for that, it's the reason why I use npm scripts and not even gulp in my other projects. I'm tired of spending hours learning and configuring build tools that never end up doing what I want anyway.
But since the vue-cli tool no longer includes the build command, I'm a bit stuck. Is there really no more CLI app to build vue files at all? And if so, what would be the smart way to use vue without webpack? Template strings are not maintainable at all, and <script type="text/x-template"> don't work when you want to use multiple components from multiple files in the same page.
I realize your question says 'without webpack' but you may be interested in backpack - a CLI app i came across for building Vue.js without requiring you to write any configuration code. It is basically webpack preconfigured as a minimalistic build system for Node.js. It provides two commands, dev for live reload enabled development and build for building you project.