In web project server side/backend is packed and bundled by webpack in node mode (https://webpack.js.org/configuration/node/) to achieve one independent bundled distributed file, like for client/frontend side.
But there is one problem: that project is dependent on Socket.io library, and server-side part of socket.io contains following line: https://github.com/socketio/socket.io/blob/master/lib/index.js#L110 , which implies load some library part at runtime.
Such behavior causes problems in bundling server side by webpack, because socket.io-client library is not required directly by require operation, and that's why does not compile into bundle.
Of course, it's potentially possible to develop own Webpack plugin, which will search and operate over require.resolve invocations, for example, by resolving target files and place them in memory file system or pack into bundle as resources. But it not simple manual work, and most probably well-known solution is exists.
For example, maybe is there already bundled version of library for webpack usage?
Related
I was learning babel and webpack and then it turns out I need to install node.js to run them both and I asked myself WHY? Then according to my research, we need node.js for webpack and babel since both of them were written in JS and to run that JS code which transpiles( for babel) and bundles up the code(for webpack). Also, another reason is that since both babel and webpack handles our JS code outside of the browser, this is the reason to use Node.js. Are these reasons true?
According to the Node.js website -
Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript engine.
Webpack and babel (along with many other tools you might use for frontend development) are written in javascript and since they are command line tools, they need a way to run outside of the browser (directly on your machine).
They could have used some other language to write the tools but since they chose to write them in javascript, Node.js is the only feasible options right now.
In case you are interested, the original creator of nodejs
Ryan Dahl has built another secure runtime environment for Javascript/Typescript called Deno
Yes, at the moment the node.js project is non-portable by full open source disclosure nor extension to port node.js commonjs without a just in time transpiler with a service worker on a server.
Definitions: FHC = "from half court"
Babel and webpack
(1) transpile/move (write&read, not ln -s sym...bolic link) & (2) compost/pile onto a JIT target,
like v8 or other browser-javascript-interpreters. v8 on a service worker can compile on the edge just in time for interpretation in a browser v8 environment but still on the cloudflare edge server.
Declare (FHC) Allegedly, rust provides webassembly modules with the lipid [llvm-]wrappings
that nucleic acid exocytosis needs to be a full-blown virus, err I mean
Initiation Routine needs to be a targetable JIT extension!
A compiler/transpiler still requires it's target-scope receivable. Declare (FHC) Emit is to execute as compile is to interpret, even AST.
I am working on a project that is hosted as a monorepo. For simplification purposes let's say that inside there are three self-explanatory packages: server, a webapp client and library. The directory structure would be something like the following:
the-project
packages
server
src
webapp
src
library
src
All packages employ flow type notation, use a few >ES5 features and, for this reason, go through babel transpilation. The key difference is that transpilation of the webapp package is done via webpack, whereas server employs a gulp task that triggers script transpilation through the gulp-babel package. library is transpiled automatically when web is built.
Now, the problem I have is that for server to build, babel requires library to be built first and its package.json to specify its (built) main JS source file so its transpiled artifacts can be included. As you can imagine, this would quickly become problematic if the project were to contain multiple libraries that are actively being developed (which it does), as all would require building, including any dependent packages (like server in this simple case).
As an attempt to overcome this annoyance, I initially thought of using webpack to build the server, which would take care of including whatever dependencies it requires into a bundle, but I ran into issues as apparently webpack is not meant to be used on node JS applications.
What strategies are available for building a node JS application requiring Babel transpilation, such that the application's source files as well as any dependencies are built transparently and contained in a single output directory?
Annex A
Simplified gulp task for transpilation of scripts, as employed by server.
return gulp
.src([`src/**/*.js`], { allowEmpty: true })
.pipe(babel({ sourceMap: true }))
.pipe(gulp.dest('dist'));
As can be seen above, only server's own source files are included in the task. If src were to be changed to also include library, the task would emit the dependencies' artifacts in server's own output directory and any require('library') statements within would attempt to locate the built artifacts in packages/library and not packages/server/dist, thus resulting in import failures.
First of all, I am not sure what your server is doing. If it is doing a database connection or some calculations then I would not recommend it to be built by webpack. Whereas If your server is just doing Server-Side Rendering and making some API calls to other servers then I would recommend it to be bundled using webpack.
A lot of projects follow this philosophy. For example, you can take a look at something similar, I have done in one of my personal projects [Blubus]. Specifically, you might be interested in webpack-server-config. And also you can take a look at how big projects like spectrum does it.
I'm currently working on a React application that's consuming a React library we also develop.
Currently, the process is to copy over the dist folder of the library over to the node_modules folder of the application.
To resolve the tedious nature of this, I thought the solution would be simple: to npm link the package in our application, and have the JSX/React components run through the application's babel-loader. That way, we'd also get webpack's dev server to watch for changes in the library and refresh automatically.
The problem with this is that the library's babel settings are different from those of the consuming application. For instance, root imports in the library (e.g. import ~/some-module) are supposed to resolve from the root folder of the library, but instead, they resolve to the root folder of the application, resulting in errors, because the only babel configuration it uses is the .babelrc from the application.
I tried adding separate webpack config rules to make exceptions for the library, but now it feels kind of hacky. In addition to that, the webpack dev server runs incredibly slow to boot up, presumably because it's running a babel transformation on the library too.
Is there an easier way to do this? Like telling webpack that "for this library in node_modules, use its own configuration file, and respect all of its own babel settings and relative imports?"
Some questions to put angular2 web project to production environment
We do development on lite server but what is best for production? Is is some other server module of nodejs? Technically we can have any server (apache, tomcat, etc).
How should we do source code management for below context.
browser must include js files so project should have js files when deployed
In standard java project we just commit .java files and uses jenkins (may be other tools) to compile and make the deploy-able structure
Should we follow same strategy here? i.e. don't commit compiled js files and deploy using some node compiler which takes ts files and compiles it to js
What is the best way to minify/obfuscate the js files
I know a way using outDir and outFile with grump but I don't want every files tobe included in one minified file because it kills the concept of lazy loading
Is there a way to minify and obfuscate js files on compile time only?
What enableProdMode() do? How it is different than not using it?
Here are some answers to your questions:
Angular2 applications only consist of static files so they can be serve by any static Web servers or server applications that can define static folders (Express, ...)
Regarding source code management, you must have a packaging phase to optimize the application loading (gater files, uglify, ...). Your source code must contain your TypeScript files (or JS files if using ES5 or ES6). Such packaging can be done using Gulp for example. Your Jenkins server will be able to checkout the source code, build it and execute tests.
In fact, when not using the outFile property of the TypeScript compiler, you won't be able to gather all the JS compiled files into a single one since anonymous modules will be created within each JS files.
See this question for more details of this:
How do I actually deploy an Angular 2 + Typescript + systemjs app?
Regarding prod mode, here is an extract of the documentation:
Disable Angular's development mode, which turns off assertions and other checks within the framework.
One important assertion this disables verifies that a change detection pass does not result in additional changes to any bindings (also known as unidirectional data flow).
Ok, so modules written for node.js can be combined into bundles with browserify.
But just in case I only have a bunch of bundles created by browserify and not the source, would it still be possible to 'require' or otherwise use these bundles and their contents in a node.js environment besides the browser? (granted that the code does not do anything browser specific)
Ok, so modules written for node.js can be combined into bundles with
browserify.
Firstly I am not sure what you mean by this, as browserify was created to do the opposite. Browserify was made to allow the use of node's require() statements in the browser.
But just in case I only have a bunch of bundles created by browserify
and not the source, would it still be possible to 'require' or
otherwise use these bundles and their contents in a node.js
environment besides the browser? (granted that the code does not do
anything browser specific)
Yes in short, as long as the modules do not use the global window scope because window is undefined in node.js. Common helper packages like lodash, axios, moment, bluebird, and q promises all work in node.js.
Generally though, packages are often modified to work in both the browser and node.js. There is a browser attribute option in package.json files that allows you to specifically target the browser when publishing npm modules. Often files designed for the browser are minified down to one file because of how files could potentially be imported into the browser. This is not necessary with node and there may be many files in a node project.