I've searched all over google and checked out the official docs for Webpack but have not had any luck finding a tutorial/guide/plugin to even do this. Has anyone done this before or should I just drop webpack altogether and go for a grunt-maven-war file generator instead?
Well, there is nothing special in building spring-boot with webpack. You can install node globally, you can install it during build...
You just add plugin to pom.xml to run node command i.e. (https://github.com/eirslett/frontend-maven-plugin)
And that actually it. It runs webpack and you get your js, css, fonts, ... files in some folder. Now you proceed like it is usual static assets, pack them into war and enjoy.
Related
I'm attempting to use PostCSS to fix the problem where 100vh doesn't account for the browser/navigation bar on mobile devices.
https://github.com/Faisal-Manzer/postcss-viewport-height-correction
The problem is, I have no idea how to set it up and the instructions assume I know how. I have very little experience with JavaScript and don't use any frameworks or know how to, I just do everything in VS Code with no plugins.
I installed the PostCSS extension in VS Code but am unsure what to do next.
The installation says:
"And then add this javascript to public/index.html (for React), or add to template.html (for Preact)."
I don't use React (I don't think?), so what do I do instead?
Then it says:
"Check you project for existed PostCSS config: postcss.config.js in the project root, "postcss" section in package.json or postcss in bundle config.
If you already use PostCSS, add the plugin to plugins list:"
Would postcss.config.js be in my root folder? Am I supposed to create this file?
It then says to do this:
module.exports = {
plugins: [
+ require('postcss-viewport-height-correction'),
require('autoprefixer')
]
}
I added that to my .js file (Or does it go in the css file?), and am getting an error "module is not defined."
Could someone walk me through this as if I had no idea what I'm doing and have only been using JavaScript and VS Code for a week? Because that's where I'm at.
I'm on Windows if that makes a difference.
Part of the instructions say to do:
npm install --save postcss-viewport-height-correction
I don't know where to enter this command. I've come across similar instructions several times, and looking up "How to do npm install" doesn't produce any results. I've largely been avoiding using frameworks and extensions and plugins with JavaScript because I can never figure out how to use them, and every guide I can find assumes I already know what it all means.
Might be a long winded answer, but I'll try to respond to everything.
PostCSS is a JS-based tool for transforming styles with JS plugins. Typically, you use it as a plugin into your front-end build tool such as Webpack, Rollup, etc. You can also use it as a CLI app, manually running your build.
I just do everything in VS Code with no plugins.
Which editor you use is irrelevant. How are you building this content? Is it just plain HTML and CSS files?
I installed the PostCSS extension in VS Code
That extension is just for getting your editor on the same page as your PostCSS config. For example, you might write some CSS with your PostCSS config that will look like totally invalid CSS to your editor, and it would throw errors at this. That extension ensures it follows the same altered rules as your CSS now does, since you're using a tool that changes the rules.
Would postcss.config.js be in my root folder? Am I supposed to create this file?
Yes
I added that to my .js file (Or does it go in the css file?), and am getting an error "module is not defined."
JS, but it's throwing errors because you need to install it
Part of the instructions say to do:
npm install --save postcss-viewport-height-correction
I don't know where to enter this command.
From your terminal. NPM (and Yarn, if you run across it) is a CLI tool for installing Node packages, like PostCSS here.
Here are the instructions for installing Node & NPM: https://docs.npmjs.com/downloading-and-installing-node-js-and-npm
My web development is principally intranet sites and web front-ends for embedded devices using NodeJS.
My current structure is to have everything in one NPM package. I run NodeJS behind Nginx, and let Nginx serve css/image/client-side-javascript files directly from public.
I'm starting to use VueJS and Vuelidate, both of which use the now ES6 modules system - e.g. import { required, minLength } from 'vuelidate/lib/validators'.
While I've (rather hackily) made these work with my current structure, I think the time has come to get into the world of Javascript build-systems/bundlers.
If I use VueJS's preferred option of WebPack, how should I change the structure of my code?
Should I have one NPM package for the frontend (generated by vue-cli init) and another for the Express backend app?
Should I put my Express App into the generated Vue frontend package?
Should I use browserify to do the job of WebPack and stay with my existing structure?
Or something else entirely?
I’m not sure why you’re intent on putting your JavaScript code in other packages. If you have an application then you can keep your raw JavaScript files in there, along with the build script(s). Someone should be able to check your application out and be able to build it.
If you’re looking to get started with a build system, then a nice “bridge” might be to use Mix, a project created by Laravel for building front-end assets such as Sass and JavaScript. It uses Webpack under the hood, but in turn exposes a more user-friendly, fluid API.
If you go down this route, then you could put your raw JavaScript files in a lib/ or src/ directory. You could then use Mix to compile these components like this:
mix.js('lib/your-entry-point-script.js', 'public/js/app.js');
Your entry point script would just be the script that requires all your other scripts and components and the script that you want “built”. Mix would then compile that and place the resultant script at public/js/app.js.
Mix itself is just a npm package, so all you need to do is npm install laravel-mix --save-dev.
You can read more about Mix at https://laravel.com/docs/5.7/mix
I have an existing application in Angular 1.6.
We are currently using grunt and bower to build the application. Now the requirement came to migrate the existing application to webpack and removing grunt and bower. Anyone can give me the right suggestion, how to approach for the same. I am struggling with entry point, bundle path and the loader I am supposed to put in webpack config. The index.html, which script tags to remove and how to include the bundle file. Any guidance would be appreciated.
I have an Angular application which is build with the Angular-CLI. I want to deploy this project to a Spring-Microservice. When i deploy the build, which generated with the cli-command ng build --prod the application works fine.
But: I want to deploy the Original files including my typescript files to the Microservice so i can see where my console-logs come from (which line in which file, just the same as when i run the application locally with "ng serve").
A few months ago, i had a Angular-project which i started with the Angular Quickstart. I ran this project with NPM (commands: npm install and npm start). This project transpiled the typescript-files to javascript, and for this reason, this project is deployable and works fine.
But my CLI-project dont do that, so it is not deployable.
How can I deploy my application as described?
In this presentation, I generated an Angular project with CLI, generated a REST server using Spring Boot, and showed how to deploy this Angular app under the Spring server https://youtu.be/k8r76d8QzXs?t=870.
To be able to debug your Typescript code with prod bundles, use add the --sourcemaps option:
ng build -prod --sourcemaps true
When you build an Angular project with the production flag the Angular CLI creates and the sourcemaps (you can identify them from their extension .map.js) of the minified Javascript files.
The easiest way to go is to deploy all the generated files.
When you open the developer tools of the browser to debug them the browser recognize them, and generates the unminified Javascript files. You can find them on Sources Panel. (e.g. Chrome)
So you don't need the original Typescript files
I am not sure, if you can see on your console when you log something, the exact file and line where the original code is, from a minified Javascript file.
Question 1 :
I am installing my project dependency libraries using npm and it gets stored in the npm_modules folder. Is it necessary to keep the copy of library like angular.js,angular-route.js in lib folder or vendor folder? I could see few people are using lib folder or vendor folders to store the library in the permanent manner. I am confused by seeing this.
Question 2:
Do I need to copy/paste the node_modules folder to production or just run the npm install command on the project folder's command prompt to install all the dependencies in production. How does a dependency library get promoted to production?
Thank you kindly for your advice.
It all depends on how you need to deploy your site to production, really. Ultimately, you will probably want to bundle all your JS files into one or a few files, which are minified and sent with gzip compression.
How you bundle them is up to you. There are quite a few options:
Browserify
Webpack
Grunt / gulp build process
And many more besides
As to whether you need to keep a copy of these bundled javascript files under version control, well I think that boils down to 1 key question: can you run a build process (such as one of the tools using NodeJS) on the production server, or on a build server that creates a zip file or installer? If so, then you don't need to include them, just get the build server or production server to check out the latest copy from version control, npm install and then run the build process.
But if the best you could do is have the production server check files out from source control, then you would want to include the final versions of the files to use in the repository.
Keeping generated files, such as your bundled javascript files, in your source control repo should be avoided where possible. Because otherwise, every commit has to contain the changes to the source files, and the corresponding change to the generated files as well. And the latter is just noise, and has to be ignored by every developer looking at a diff/patch for a commit.