Using webpack to bundle a custom yeoman generator - javascript

I'm relatively new to Node in general, including webpack and yeoman, so the solution might be simple.
I built a custom yeoman generator that generates html and wish to use the generator in a browser (so html can be generated client side in the browser). I figure webpack could help me solve this solution but I'm hitting some module dependency snags when trying to bundle the generator.
Specifically, I'm getting several errors in regards to missing fs modules and issues bundling json files. From my understanding, setting target: 'node' in the webpack.config.js file resolves the fs issue, but unfortunately since I''ll be using this bundle in the browser I have target' set to 'web'. As per the json errors, I'm trying to include json-loader like so:
module: {
loaders: [
{ test: /\.json$/, loader: "json-loader" }
]
},
but forwhatever reason, json-loader cannot be resolved when webpack is run.
Any ideas for fixing either of the dependency issues?

Related

Is webpack a suitable tool to bundle a Node.js backend code? [duplicate]

I was just wondering, I started using Webpack for a new project and so far it's working fine. I almost would say I like it better than Grunt, which I used before. But now I'm quite confused how and or I should use it with my Express back-end?
See, I'm creating one app with a front-end (ReactJS) and a back-end (ExpressJS). The app will be published on Heroku. Now it seems like I should use Webpack with ExpressJS as well to get the app up and running with one single command (front-end and back-end).
But the guy who wrote this blogpost http://jlongster.com/Backend-Apps-with-Webpack--Part-I seems to use Webpack for bundling all back-end js files together, which is in my opinion really not necessary. Why should I bundle my back-end files? I think I just want to run the back-end, watch my back-end files for changes and use the rest of Webpack's power just for the front-end.
How do you guys bundle the front-end but at the same time run the back-end nodejs part? Or is there any good reason to bundle back-end files with Webpack?
Why to use webpack on node backend
If we are talking about react and node app you can build isomorphic react app. And if you are using import ES6 Modules in react app on client side it's ok - they are bundled by webpack on the client side.
But the problem is on server when you are using the same react modules since node doesn't support ES6 Modules. You can use require('babel/register'); in node server side but it transipile code in runtime - it's not effective. The most common way to solve this problem is pack backend by webpack (you don't need all code to be transpile by webpack - only problematic, like react stuff in this example).
The same goes with JSX.
Bundling frontend and backend at the same time
Your webpack config can have to configs in array: one for frontend and second for backend:
webpack.config.js
const common = {
module: {
loaders: [ /* common loaders */ ]
},
plugins: [ /* common plugins */ ],
resolve: {
extensions: ['', '.js', '.jsx'] // common extensions
}
// other plugins, postcss config etc. common for frontend and backend
};
const frontend = {
entry: [
'frontend.js'
],
output: {
filename: 'frontend-output.js'
}
// other loaders, plugins etc. specific for frontend
};
const backend = {
entry: [
'backend.js'
],
output: {
filename: 'backend-output.js'
},
target: 'node',
externals: // specify for example node_modules to be not bundled
// other loaders, plugins etc. specific for backend
};
module.exports = [
Object.assign({} , common, frontend),
Object.assign({} , common, backend)
];
If you start this config with webpack --watch it will in parallel build your two files. When you edit frontend specific code only frontend-output.js will be generated, the same is for backend-output.js. The best part is when you edit isomorphic react part - webpack will build both files at once.
You can find in this tutorial explanation when to use webpack for node (in chapter 4).
This is my second update to this answer, which is beyond outdated by now.
If you need full a stack web framework in 2023, I'd recommend nextjs (which is built on top of react). No need to go around setting up anything, it just works out of the box, and is full stack.
On the other hand, if you need to compile your nodejs project written in typescript (which you should use as much as you can for js projects), I would use tsup-node.
You don't need to be a genius to imagine that in 3-5 years I'll come back to this and say this is really outdated, welcome to javascript.
This answer is outdated by now since node now has better support for ES modules
There's only a couple of aspects I can redeem the need to use webpack for backend code.
ES modules (import)
import has only experimental support in node (at least since node 8 up to 15). But you don't need to use webpack for them work in node.
Just use esm which is very lightweight and has no build step.
Linting
Just use eslint, no need to use webpack.
Hot reloading/restart
You can use nodemon for this. It's not hot reloading but I think it's way easier to deal with.
I wished I could refer to a more lightweight project than nodemon, but it does do the trick.
The blog post you shared (which is dated by now) uses webpack for having hot reloading. I think that's an overkill, opens a can of worms because now you have to deal with webpack config issues and hot reloading can also lead to unexpected behaviour.
The benefits we get from using tools like webpack on the frontend don't really translate to backend.
The other reasons why we bundle files in frontend is so browsers can download them in an optimal way, in optimal chunks, with cache busting, minified. There's no need for any of these in the backend.
Old (and terrible, but maybe useful) answer
You can use webpack-node-externals, from the readme:
npm install webpack-node-externals --save-dev
In your webpack.config.js:
var nodeExternals = require('webpack-node-externals');
module.exports = {
...
target: 'node', // in order to ignore built-in modules like path, fs, etc.
externals: [nodeExternals()], // in order to ignore all modules in node_modules folder
...
};
to use Webpack for bundling all back-end js files together, which is in my opinion really not necessary.
I think you are absolutely right. It's not necessary at all. I've been researching on this topic for a while. I've asked lots of questions on this topic, and up to this day, I haven't found yet a single "real" reason for one to use webpack on a Node.js back-end.
I'm not saying you can't or shouldn't set up a webpack-dev-server to develop your back-end code locally. But you definitely don't need to bundle your backend code on your build process.
webpack bundles are meant for the browser. Take a look at its official docs: Why webpack?. Historically, browsers never had a built-in module system, that's the reason why you need webpack. It basically implements a module system on the browser. On the other hand, Node.js has a built-it module system out of the box.
And I do re-use all of my front-end code for SSR on my server. The very same front-end files are run on my server as-is without any bundling (they are just transpiled, but the folder structured and number of files is the same). Of course I bundle it to run on the browser, but that's all.
To run on your Node.js server, simply transpile it with babel, without webpack.
Just use ["#babel/preset-env", { targets: { node: "12" }}], on your babel config. Choose the Node version of your backend environment.
backend
dist_app // BABEL TRANSPILED CODE FROM frontend/src
dist_service // BABEL TRANSPILED CODE FROM backend/src
src
index.tsx
frontend
src
App.tsx
public // WEBPACK BUNDLED CODE FROM frontend/src
You can perfectly render your frontend code on the server, by doing:
backend/src/index.tsx
import { renderToString } from "react-dom/server";
import App from "../dist_app/App";
const html = renderToString(<App/>);
This would be considered isomorphic, I guess.
If you use path aliases on your code, you should use babel-plugin-module-resolver.

Webpack to "ignore" some entrypoints

I'm using Webpack to build my front end components.
I have some React components which need classic webpack bundling, though I also have some vanilla JS files.
Those latter files are independent, so they won't get imported from React files. From my understanding, they need to be defined as entrypoints, so that Webpack reads and processes them. So far, so good.
The trouble is that I'd like Webpack to load them with Babel, and that's all, only give me back the JS file processed through Babel, I'm not interested in a bundle for these files.
Is it possible to do that? Only get the result of the babel loader, and not produce a bundle for some entrypoints?
Maybe I shouldn't use Webpack at all for these files?
Or maybe I should just set these bundles as 'library' so that I can reach them from the HTML pages?
What do you think guys?
Thanks by advance ;)
depends on how easy it is to find these files. I have a project that has similar requirement. What I have done is:
1/ put the vanilla js file in third_party/lib/
2/ import/require them in my current project
3/ set up my webpack.config.js as follows:
module.export = {
module: {
rules: [{
test : /.js$/,
exclude : /node_modules|third_party/,
loaders : ['babel-loader' /* other loaders? */],
},{
test : /third_party.*?\.js$/,
use: [{
loader : 'babel-loader' // or other loaders
},{
loader: 'file-loader'
options: {
name : '[path][name].[ext]',
outputPath : 'dist/third_party'
}
}]
}]
}
}
oh, you will need to npm i --save-dev file-loader
edit: I should clarify that this will bundle the vanilla js file as separate files to your main bundle, so you will have to import them by script tags yourself in your html file. (or if they were worker files, called by your script)

webpack load AMD modules without bundling

I'm migrating a web app from requireJS to webpack.
With requireJS, I have different configurations depending on the environment.
For live environment I use r.js to minify and bundle all of my
modules and their dependencies into a single file. Afterwards, I add
almondJS to manage the dependencies and then I load my js bundle like the following:
<script src="bundle.min.js"></script>
For my development environment, I Load requireJS like this:
<script src="require.js" data-main="/main-config"></script>
and requireJS will use my configuration file specified by data-main, to load modules and their
dependencies asynchronously
As you can see, with requireJS module loading and bundling are two separate processes and that allows me to debug AMD modules during development without needing sourcemaps
How can I achieve this scenario using webpack as a module loader only without bundling during development ?
If this is not possible, is there any other way I can see my source files in the browser debugger without generating sourcemaps?
How can I achieve this scenario using webpack as a module loader only without bundling during development ?
Webpack will always bundle, despite the envieronment.
If this is not possible, is there any other way I can see my source files in the browser debugger without generating sourcemaps?
If your code is transpiled/compiled, you'll need sourcemaps to see that. There is no way to workaround that.
It's true that if your code is transpiled then you'll need sourcemaps. But it is possible to get around bundling though. Yes, webpack will really always try to bundle, but with plugins the code can be taken out of the bundle and placed in the output directory as if it was simply run through the transpiler.
I have a node application that I want to simply transpile to ES5 file-by-file and not bundle anything. So my config to do that is roughly this:
let config = {
entry: [
glob.sync(srcDir + '/**/*.js') // get all .js files from the source dir
],
output : {
filename : '[name].rem.js', // webpack wants to bundle - it can bundle here ;)
path: outDir
},
resolve: {
alias: {
'app': appDir
}
},
plugins: [
new RemoveEmptyScriptsPlugin({extensions: ['js'], scriptExtensions: /\.rem\.js/}) // for all .js source files that get bundled remove the bundle .rem.js file
],
module: {
rules:[{
test: /\.jsx?$/,
type: 'asset/resource', // get webpack to take it out instead of bundling
generator: {
filename: ({filename}) => filename // return full file name so directory structure is preserved
},
use: {
loader: 'babel-loader',
options: {
targets: { node: 16 },
presets: [
['#babel/preset-env', { modules: 'commonjs' /* transpile import/export */}],
]
}
}
}]
}
};
// Since the code does not go through the full pipeline and imports are not getting resolved, aliases will remain in the code.
// To resolve them it takes to hack the aliases object into the babel config
config.module.rules[0].use.options.plugins.push(['babel-plugin-webpack-alias-7', {config: {resolve: {alias: config.resolve.alias}}}];
But then it appeared that the currently published babel-plugin-webpack-alias-7 does not support providing an Object to the config option so I had to patch the plugin https://github.com/shortminds/babel-plugin-webpack-alias-7/pull/22
Ah, and then the webpack-remove-empty-scripts plugin had an issue with my idea so I had to patch that too https://github.com/webdiscus/webpack-remove-empty-scripts/pull/6

Why adding babel-loader in webpack conf file?

I am new to webpack and have seen some examples as following:
module: {
rules: [
{
test: /\.js$/,
loader: 'babel-loader',
exclude: /node_modules/
},
// ....
Why is this necessary since webpack auto transpiles es6 to es5?
Edit:
Ok, it DOES NOT transpile automatically unless instructed to do so.
Why is this necessary since webpack auto transpiles es6 to es5?
Webpack does not auto-transpile ES6 to ES5. It is simply a build tool. It does nothing but execute the plugins & loaders you tell it to.
But the es6 code I wrote get transpiled to es5 even without this "babel" rule
I don't see it transpiling ES6 to ES5.
The first example I looked for in your code was the conversion of let to var in the bundled code since this is probably the most commonly used ES6 feature.
With babel-loader, let gets converted to var (and some other fancy maneuvering). Without, it remains let.
To explore this, I commented out UglifyJS so the bundle was readable and ctrl+fed the file. You should be able to see this same behavior.
If you're expecting import to be converted to require, this won't happen as webpack just reads the file and loads it into the bundle. So, no require & no import appear in the bundle. This isn't transpilation, though. It's just a function of how webpack's bundling process works (searching for & injecting dependencies into the bundle).
Bonus points:
I would recommend adding your dist directory to .gitignore. Typically, you don't want your bundled code version controlled. You should rely on your build tools to handle this (you can add webpack to your package.json's postinstall if you want to simplify the installation for consumers of your project).
In hindsight, I realize you probably only added the dist directory because I asked to see the bundled code. Sorry! :p But I'll leave this here in case it helps someone else in the future.

Bundling and minification of angular2 project, Js and Html

Been working on an angular2 project for a while now, after updating it from angular1 (loving angular2 btw).
Now i would like to bundle the project, but unsure what is the best bundler to use?
Also i see some posts saying that they split the bundle into multiple files (like app.bundle.js and vendors.bundle.js) and others have 1 large file. What is the best method? I always throught that many files were better because browsers can download multiple files at the same time?
Do you need to use a gulp task for all this, or something else completely?
Also, how can i minify the HTML templates in an angular2 app?
You can either use Webpack or Systemjs-Builder to bundle your app. There are tons of seed projects from which you can take hints e.g. this and this and you can use this in your gulp task to inline the templates with your build.
Now i would like to bundle the project, but unsure what is the best bundler to use?
All answers to your questions will be subjective, but it is factual that Webpack offers plugins and configuration settings to suit your needs.
Also i see some posts saying that they split the bundle into multiple files (like app.bundle.js and vendors.bundle.js) and others have 1 large file. What is the best method?
Splitting into multiple files is definitely the most common method. It allows you to keep your application code separated from your dependencies, which makes debugging less of a nightmare.
The part of your Webpack config file that handles this might look something like this:
// our angular app
entry: { 'vendor': './src/vendor.ts', 'main': './src/main.ts' },
// Config for our build files
output: {
path: '',
filename: '[name].bundle.js',
sourceMapFilename: '[name].map',
chunkFilename: '[id].chunk.js'
},
Do you need to use a gulp task for all this, or something else completely?
If you use Webpack, then Gulp is not required at all. I'd recommend just using NPM scripts. Don't quote me on this, but I think Webpack can just flat out replace Gulp for Angular2 projects.
Also, how can i minify the HTML templates in an angular2 app?
Webpack has a HTML minify plugin for this.
You can use it like so:
loaders: [
{
test: /\.html$/,
name: "mandrillTemplates",
loader: 'raw!html-minify' // raw is another loader
}
]

Categories

Resources