Develop Reference

Where to install webpack using client/server folder structure

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.

Why use bin/www and not index.js?

The express-generator tool creates a file called bin/www and uses it as the application's main entry-point. I believe I've seen a couple of other modules do this as well, but the vast majority simply use index.js.
What is the rationale behind this? Of course I understand why you would split the server and the code for setting up the program into a separate modules, but why bin/www and not index.js? Why nest the main-entry point to a program two levels deeper than the stuff it calls? And remove the file-extension, making it even less descriptive?
Is there a clever, non-obvious reason behind this? Should I use this for my node-modules as well?
Thank you!
[edit]:
All good answers, thank you folks! I've accepted the one pointing out that this is standard behaviour for packages that include executables. Here's some more reading I've come across on this:
https://docs.npmjs.com/files/package.json#bin
https://blog.npmjs.org/post/118810260230/building-a-simple-command-line-tool-with-npm

You're used to running npm run, but not sysadmin. He will look for executables (attribute x) in thebin directory.
The entry point index.js is for node module. All packages that provide commands to run on the console contain the bin directory.
The extension is removed because it is not a script, but as a program. And these do not have extensions.

express-generator create a basic structure for an express application. By convention, the entry point of the app is index.js or app.js. In fact, express-generator create an app.js at the root of the application with the initial setup of express.
Also by convention, the bin/ directory is used for binary files, and by extension for the scripts you can directly launch (note the shebang at the first line of www file). This is common on Linux that binary file has no extension and it could explain the choice to keep this habit for this file.
www, by convention again, is used for naming web application (like /var/www/html in Apache server)
Anyway, as the documentation says,
The app structure created by the generator is just one of many ways to
structure Express apps. Feel free to use this structure or modify it
to best suit your needs.
See also this answer who talk about the core structure of express between version 3 & 4, with the removing of external module.

How to organize node,js/webpack project with server, client, and shared code?

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.

Hosting Angular 2 app

I'm new to Angular 2, I know host Angular 1.x on shared hosting like GoDaddy, but I don't have idea how publish Angular 2 application, for example I have this structure folder:
angular2-quickstart
--app
app.component.ts
main.ts
--node_modules
--typings
index.html
package.json
styles.css
systemjs.config.js
tsconfig.json
typings.json
What file i need to upload on ftp?
I don't tried anything because I don't know how to proceed
Thanks in advance!

As a component based language, angular 2 includes some caveats in it's deployment process.
First, the files used in development environment aren't necessarily shipped to production. In short, you'll only need to upload .js, .html and .css files .
Second is that even if your application works deploying only the files mention above, it's advisable to include the following process:
Bundling: Compiling all the .js files into single files. For instance, vendor.js could include all third party libs and bundle.js would include all application .js files. (Bundles are import for performance reasons, but bear in mind that with the arrival of http 2, this process will be abandoned)
Minification: it's a standard process in all web apps, but now you only minify bundled files.
Take a look in this article, as it give some examples of tools that can help you with deployment process.
http://www.ninjaducks.in/hacking/angular-setup/

If you don't have a backend, free hosting sites will usually look for an index.html to begin their job. Hence, your folder structure is correct but you will need to upload the js files instead of the ts files.

I think that one popular workflow is to gulp-typescript your .ts files, and send the resulting .js files into a distribution folder. The many .js files could also be "gulp-concatenated" (gulp-concat) into one file.
Of course you'll need to be sending your html and css files as well.
Since the Angular2 library relies heavily on what's in the node_modules folder as well, you would need to upload your package.json and npm install on the server side. You could try uploading the node_modules but the upload takes a lot of time.

You need to build angular2 project using tools like webpack or angular-cli - which also uses webpack post beta.14 release. Webpack will create a distribution directory - dist - which you can deploy to the server. Webpack bundles all the code into a single file which it puts inside the dist folder. Here's a good resource to understand the code and deployment structure of angular2 app: https://github.com/mirkonasato/angular2-course-webpack-starter
Clone the above directory, run "npm install" to install all dependencies and run "npm run build" you will see the distribution folder - dist - which you can deploy.

Well, you can run ng build in your root application directory. It will create a dist directory containing the app and files. You can put this directory into the page the webserver will look for the index.html

How to prepare grunt to prepare dist folder with app.js?

I'm currently playing around with Yeoman Angular Fullstack Generator. That's pretty cool and works as expected. Since it uses grunt, it's possible to run grunt serve dist so that it starts the server with my uglified and concatenated files...
BUT:
Last week I found modulus.io (nodejs cloud hosting like heroku) and they were offering a free evaluation phase. Problem: They expect that my project has an app.js so they can start it with node app.js.
Question:
Do you guys know how can I use grunt to generate a dist folder just for modulus.io, including all contents of the already generated dist folder (currently just frontend code) + all needed server-side javascripts + an appropriate app.js (that uses express and the contents from the dist folders) and the package.json file?
Any help would be appreciated. :) I think a similar task must exist somewhere since you might have this problem on any other cloud hosting platform. Unfortunately I couldn't find a proper solution
Regards,
Sascha

In short, modulus.io is just looking for an entry-point into the application. It can be called whatever you like, so long as in your package.json file you have a line that tells it what to launch, ie. "main": "dist/app.js".
See: https://modulus.io/codex/projects/app-guidelines for more info.
The full stack generator that you are using should have generated all this for you however...?
EDIT: Running a simple grunt command will create a \dist directory that is ready to be uploaded.