Im building a React Nodejs web application and Im trying to understand how to bundle the frontend with webpack. [
This is my project structure
Where should I install webpack and configure webpack.config.js? Most of the project structures I have seen put the frontend folder inside the backend folder, also in some projects they also bundle the backend separately. Can someone give me an explanation on where to implement it with this folder structure? I'm really confused
This article was kind of getting to the point but didnt solve my question
Webpack should be part of the frontend repository, so it should go into the frontend/package.json. Similarly, just like frontend/eslintrc.json is your linting settings for your frontend, you should create a frontend/webpack.config.js for your frontend webpack config.
Since you're in VSCode, it looks like, when dealing with just the frontend, you could consider making things easier on yourself by going to File -> Open Folder -> select the Frontend folder, and then you can easily operate on it, its package, and everything it contains (without getting mixed up with the backend at all).
Where your frontend folder goes is up to you, but your current approach is fine - organizing to have a /frontend and a separate /backend folder in the same parent directory if you wish.
Related
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
This seems like a situation that must be incredibly common, but I've yet to find a good solution to it. I'm a little new to modern Javascript, so please forgive me (or better yet, correct me) if I'm using the wrong terminology here and there.
I'm developing a web application. It's got a server, running as Javascript (ES6, I believe - using import/export) in node.js, using express.js for a router (and built by express-cli). And it's got a client side, also Javascript, mostly Vue modules (and built by vue-cli). I admit I don't really understand a lot of the boilerplate build code express-cli and vue-cli emitted, but it does work. I am not using any of a long list of frameworks that are assumed in the many pages google found for me when I tried to find an answer to this question.
Obviously, the client and server will be sending data structures (instances of various classes) back and forth, which I know how to do. And these ought to be the same class definitions.
I made an attempt to make webpack build both server and client, and that failed, so now I've split the application into two projects, each with its own folder tree, its own package.json, its own node_modules, and I'm using just webpack-dev-server for the client and nodemon/babel for the server. A third folder contains the shared code, which is imported by the client and the server. I got this to work well enough for proof of concept, but getting both sides (and Visual Studio Code) to recognize that the shared code is part of them is turning out to be a challenge, and I'm pretty sure I'm just going down the wrong path.
So, my question is, what is currently considered the best practice (or at least, a good practice) way to structure and build a client/server application of this type? An ideal answer to this question would include both folder structure and enough of the major configuration files to help me figure out how to write mine. A reference to an up-to-date and reliable source of information on this topic would satisfy me nicely.
I suspect that the right answer includes merging everything back into a single project and doing something clever with the webpack config files and maybe project.json... but what exactly that clever thing might be has so far eluded me.
Thanks!
In my opinion, you're right to use separate folders for your node.js(server)/vue.js(client app) as they're effectively 2 separate projects.
Apart from sharing some configs, utilities and validation, the app and server typically have little overlap: they're typically doing 2 very different things, require different build tools, different runtime environments, have different security concerns, and if you consider the future possibility of leveraging your client codebase to create a native IOS/android... app the difference between the 2 codebases will only increase.
For my current project, I have a folder structure whereby my server resides in the project root and my client is in a subfolder /app. Here's an simplified outline of how I've structured my node.js/vue.js project:
constants
config.js (server environment, database connection, api keys etc)
settings.js (business logic)
pricing.js
drivers
auth.js
db-connect.js
email.js
sms.js
socket-io-server.js
models (mongoose database models)
node_modules
routes (express routes)
api.js
auth.js
schema (json schema for automated validation)
login-validation.js
register-validation.js
services
billing.js
validation.js
app (this is my client sub-project sharing some server modules)
public (the output of the webpack client bundle including index.html)
src (ES6 source code, images, SASS/Stylus, fonts etc)
css
html (handlebars templates)
index.hbs
home.hbs
account.hbs
pricing.hbs
img
js
api
client-services
socket-io-client.js
store.js
router.js
vuex-utils.js
dom-utils.js
components (Vue components)
Profile.vue
Payment.vue
index.js (root and entry point for webpack)
webpack.config.js
.env.development.js
.env.production.js
package.json
server.js (node.js server root entry point)
This is by no means prescriptive. Notice, that I've organized the project files largely by function. Here's a link to an article proposing structuring around features.
A shared (client/server) module folder has pros and cons. The main downside I can see is that module sharing changes during development. For that reason my server codebase and modules reside in the project root folder - and some are also imported by the client app. The project root folder then naturally hosts a shared package.json and node_modules folder.
As your app develops, and you gain insight, it's fine to re-structure as the need arises (some IDEs make refactoring easier than others). If the Visual Studio Code IDE or webpack are not working well with your folder structure, it may be a configuration issue or the problem may stem from incorrect require/import paths. IDE inspections may help you find those errors or your IDE may struggle to be useful because of those errors.
My IDE (webstorm) and webpack v4 have no problems with the above folder structure or the location of modules in general (I have re-structured my app in many different ways) and got more adept at optimally configuring my IDE and webpack.
Webpack is very specific about the location of it's configuration file, input/output paths, whether it is executed from the project root or /app folder and it can take a lot of time to get it working properly. Nevertheless, it will locate modules referenced by the correct require/import paths. Here's the part of my webpack.config.js that sets up file entry/output.
const sourcePath = './src';
module.exports = {
entry: [
sourcePath + '/js/index.js'
],
output: {
path: __dirname + '/public', //location of webpack output files
publicPath: '/', //address that browser will request the webpack files
filename: 'js/index.[contenthash].js', //output filename
chunkFilename: 'js/chunk.[contenthash].js' //chunk filename
},
...
I've located my webpack.config.js and execute webpack inside the /app subfolder. My package.json scripts section to start the node.js server and have webpack build & watch my app files is:
"scripts": {
"start": "if [$NODE_ENV == 'production']; then node server.js; else nodemon server.js; fi",
"build": "cd ./app; webpack;"
},
Which allows me to start the node server with:
> npm start
and have webpack watch/re-build my bundle with:
> npm run build
Visual Studio Code has a rich IntelliSense experience and a feature called Automatic Type Acquisition which should allow it to support modules you import regardless of their location. This article provides more information on configuring VS Code for node.js.
So I am using the following tutorial. I can access the localhost, but I am putting in an html file. The tutorial does not go into depth about setting up a javascript file and getting that file to transpile. Can someone help me with the setup. I have googled this topic and I keep coming across tutorials that talk about needing babel for the transpiling, yet the tutorial says
Now that everything’s ready to go, we can get webpack to watch for
code changes in our directory and transpile.
But I feel like this means it should just bundle up everything in my project since webpack is a bundling product. Further, I am confused by the call to webpack:
CMD webpack --watch --watch-polling
Does this mean I don't need to put in an entry point and endpoint? I thought with webpack I need to provide those two details, but the tutorial again is calling directly to just polling.
Thanks in advance for any help getting my structure setup so I can run webpack, react in docker.
In terms of setting up the files, I had to add
COPY wwwroot ./wwwroot
Just to get the project to display something at localhost. But I want files to be brought over automatically if possible. But I am not sure of the intent of the tutorial with regards to file structure.
I am developing an express based web application and I started following the application skeleton built by express-generator.
Next, I added to my project webpack to bundle the client side assets.
Now I am not sure where to place the front-end javascript files, if in a /src or /app folder?
In truth, I am in a dilemma between, app.js, /lib, /src and /app folders.
According to express-generator, it creates an app.js file as the main entry and thus it looks a little bit strange to have an app folder with same name of the entry point app.js.
webpack usage manual suggests a /src folder to place javascript files. But I think /src should not be exclusively for front-end javascripts and on the other hand, I would not like to mix both server and front-end javascript files in same folder.
Moreover, the Accepted Answer to the question Folder structure for a Node.js project, contradicts the previous point because it states:
/src contains all your server-side specific CoffeeScript files
So, I think that maybe /src is not the better option to place front-end javscript files and according to the Accepted answer to the question Node.js project naming conventions for files & folders I would follow the proposed structure:
/app - front-end javascript files
/bin - helper scripts
/lib - back-end express files
But is it ok to have a folder /app and a file app.js with same name? Furthermore, /app is related with front-end and app.js with back-end.
I would suggest you to just rename your main file from app.js to index.js and keep the structure proposed in Node.js project naming conventions for files & folders:
/app - front-end javascript files
/bin - helper scripts
/lib - back-end express files
Thus, there is no more misleading between /app folder related to front-end and the index.js, which is the back-end entry point.
There isn't really a "required" structure for web apps, as Abdellah stated, it's usually best to just go with what you and your colleagues are comfortable with. However, because Node.js has a built in framework, you should probably use that. The move that makes the most sense to me is to rename the app.js file, and use the structure you stated.
I think public folder is rather common in web projects.
Since it's the destination of the generated bundle, i think you can name it more explicitly webApp or whatever you want. I think it's your call and there is no rigid/best practice here. Go with something you and your team are comfortable with.
I've got two projects which I've created:
A web UI built using webpack
A Vert.x webserver written in java built using Gradle
I want to find a way to bring the resulting build dir contents of the first project into the second as the webroot which will be server up using the StaticHandler.
Is anyone aware of a clean way to do this? I want to preserve the two git projects as they are because I like using the webpack dev server for development of the UI and it generally feels cleaner to have them separated.
I was looking at potentially using the bitbucket pipelines build on my repo, however bringing the assets generated by the first project into the build of the second is where I'm facing issues.
You could create a gradle task that before that depends on the jar task (so it runs before it) executes webpack compile into the resources directory. So when your jar task runs it bundles the compiled webpack code.