I'm thinking about an app that uses electron, react and webpack. But I'm not sure if it make sense to use webpack on electron. I'm definitely sure that using webpack to the react part of an app could benefit a lot but I would like to know if it is the same thing with the electron part of an app.
Why do you need webpack for some cases even in node.js? Because CJS module resolution can cost a lot depends on your code:
https://twitter.com/samccone/status/1010584941355077632
Friendly reminder that Node startup time due to module runtime parse and compile is non-trivial. Illustrated below is the hello-world webpack common chunks example, As we can see the actual work takes < 1/4th of the time, the rest is lost to the javascript parse ghoul
This applies to Electron because it shares the exact same module resolution.
https://twitter.com/_ojkwon/status/933046538762207232
CJS without bundling
with webpack bundled
Still, it means development / deployment pipeline will change entirely, and this is not the guaranteed path of improving cost of module loading. You have to analyze your dependencies, and decide proper path for best performance.
Webpack is separate from electron. Webpack is used to bundle js files if you want to bundle your code together. There is a similar question that goes into additional detail here.
I am new to npm, react and webpack but I have a question. In npm how do you prevent a library from being included production package file?
For example, I am just building a very small component in react and on the site where I am going to place my small component. The problem is Jquery library and bootstrap is already being called in the masterpage of the site and I didn't want to call the same library again in my small application production build but I still want to use them during development(because I am only testing it on local and jquery is not called there). TIA
Appreciate your time ready this and hope I got to learn more from you. By the way I created the app using create-react-app but I already 'ejected' it, so its using the webpack 3
Take a look at Webpack externals
You can have two webpack configs, on the dev config you include the package as normal, but for your production config add externals for jquery, so it uses the global one already on the page
The ability you're looking for is named Code splitting
React loadable may be a good option for you as well
My case is that we have application with stack: AngularJS and ES5 and we want to use webpack. Migration of all of the .js files (rewrite it to ES6 Classes etc.) is a big problem because of the size of the project. Is there any way to migrate it to webpack without making full refactor? The situation that we use webpack with new modules and the other modules are only plugged to webpack (somehow) with old dependency injection etc. would be satisfactory. Do you have any idea how to do it?
I am updating the build process for an Angular 1.5.8 application, to allow development on Typescript.
After an over-complicated experience with Grunt, the current build process is simple and only uses Gulp and Browserify to build two bundles: my-lib.js and my-app.js. This way, the library, which is bigger, but more stable than my application code, doesn't have to compile so often and the compilation of the application-domain code only takes 0.1 sec. I am happy with that -- as well as the other developers.
Now we are looking forward to migrate to Angular 2.0 and want to start development in Typescript, but I'm not sure on how to integrate it on the build process and even the best approach on how to do it: should it be preferred to use tsc only to compile Typescript into Javascript and let Browserify handle the dependencies? Or should I use tsc as my main build tool and let it resolve dependencies, create mapping files and make the bundles?
Both Typescript and Gulp are evolving very fast and I cannot find documentation for this use on their documentations (1, 2). I would appreciate feedback from experienced people also working on the latest versions of these technologies.
Moving comments to answer:
We have doing very similar exercise at my organization, towards the end of it.
We have used webpack for most of the stuff, though webpack feels little grunt'y and after gulp, I am not a big fan of grunt.
We have used webpack to convert ts to js, bunding, minification. We have not used it yet for html to js string or css in js.
regarding the di part, you will have to worry about only js to ts. ts to js is not an issue as it is taken care by angular's string based di. regarding ts to ts, you will need to defined needed interfaces. Those will help you in moving those js to ts in future. Better to start with core components with least dependencies.
EDIT
Just to answer the part regarding the advantages of having gulp: specifically in the migration scenarios is, the upgrade is not going to happen in one go, so whatever is moved to TS should be handled by tsc and remaining by gulp.
Also gulp is much larger than just ts to js, we are still using it to create deployment package, inject js into html, fixing boostrap font paths, converting small images to base64, etc etc....
tsc has one purpose: to transpile (compile) typescript files.
gulp, on the other hand, is a build tool, which means it can run various tasks including compiling typescript, sass, minification, concatenation etc.
You can look here for an example on how to incorporate typescript and browserify using gulp: https://www.typescriptlang.org/docs/handbook/gulp.html
Another approach, is not to use gulp at all, but rather use npm scripts, you can see a sample here: https://medium.freecodecamp.com/why-i-left-gulp-and-grunt-for-npm-scripts-3d6853dd22b8#.a7lwcmpaf
I believe the absolute simplest way to do this is to use Zwitterion. You can read this article for a quick introduction.
Zwitterion allows you to include TypeScript directly into the browser through normal script tags. All features of TypeScript are automatically available, because the code is transpiled server-side on a file-by-file basis as it is served to the client. Under the hood, it uses SystemJS to emulate the real ES module loader behavior that will be standard in all browsers. If you need this to work in production, you can create a static build with Zwitterion. All of this eschews bundling, so you'll have to decide on what your needs are for performance. Personally, I'm betting on performance not being that big of an issue with HTTP2, and I prefer the simplest of builds to the complication that webpack and all of its friends bring.
As you are moving forward with typescript, my recommendation would be to integrate any module bundler such as webpack (my favorite) Internally it will use ts loader to transpile the code. Also along with compile, you would be able to use ts lint for static code analysis (webpack would take care of it). Webpack also helps if you want to have multiple modules created. Try out yomen https://github.com/FountainJS/generator-fountain-webapp . Once scaffolded you can refer to generated gulp files. It would give you an idea about typescript integration.
The best way to do this without overengineering your gulp setup is to use the plain typescript compiler:
1. Install typescript locally(it won't conflict with your global tsc):
npm i typescript --save-dev
2. Add tsc as npm script(inside package.json).
"scripts": {
"tsc": "tsc"
}
3. Create proper tsconfig.json for your needs and put it in the same folder as package.json
https://www.typescriptlang.org/docs/handbook/tsconfig-json.html
4. Use tsc compiler directly from gulp
var child_process = require("child_process");
gulp.task("build", function(cb) {
var tsc = child_process.spawn("npm", ["-s", "run", "tsc"], {stdio: "inherit", cwd: __dirname});
tsc.on("close", function(code) {
console.log("Tsc finished with code", code);
cb();
});
});
Tip. Use https://www.npmjs.com/package/gulp-sequence and vote up :)
I'm trying to use webpack to refactor a backbone application that uses no modularization at all.
All the models and the views are added through script tags to index.html and are globally available.
I have read a couple of tutorials about refactoring with webpack but they only seem to take into consideration the use of webpack on applications that already use modules.
Do you know if there's a way of adding webpack to an app like mine without having to refactor every single js file?
Thanks
You will have to modify each of your js files some, but Webpack will automatically treat each file as a module for you (similar to wrapping every file in an IIFE http://benalman.com/news/2010/11/immediately-invoked-function-expression/).
What you have to do is define which modules have dependencies on other modules. Module's that have dependencies need to define those. Webpack supports many module syntax's, and comes with Commonjs and AMD out of the box. Commonjs is the recommended syntax for webpack. The best place to start is probably this guide:
https://github.com/petehunt/webpack-howto