As I understand it, ng-build creates a distributable packaged version of your application. I also understand that webpack is used to bundle Javascript modules.
I ran ng build on a test project and found that it created a dist folder containing what looked like a packaged version of my Angular application. All of the .js files had been combined however my referenced .css files had been left in the original form (not bundled or minified).
Therefore, what is the difference between using ng build or webpack to do this job. Or are they complimentary? Would I potentially use both in my deployment pipeline?
Not a complete answer, but worth to note:
If your css files were not compiled, it probably means, either:
you ran ng build (a.k.a. ng build --dev) which adds default --extract-css to false:
--extract-css (aliases: -ec)
Extract css from global styles onto css files instead of js ones.
You ran ng build --prod but forgot to reference your styles as global styles in angular.cli.json:
"styles": [
"styles.css",
"assets/styles/test.component.css"
],
Once you do this you will find your css files inlined, however, you will also find them in normal format as well. Cant understand why is that..
Webpack and ng-build do pretty much the same job, which is bundling your modules to be used in a browser environment For example, the Angular module is a feature, which doesn't support in the browser, and ES 6 modules are not implemented in any browser yet, which is why things need to be bundled.ng build only for angular. we can you webpack any UI related applications including angular.
Related
I am tasked with figuring out how to publish a component library my team is working on. These components will be consumed by various internal applications within the company. I have the following constraints:
The library will be consumed as an npm package from internal local
repository. (this part I have figured out)
Components should be
compiled to JavaScript with typescript interface (*.d.ts) references
within the package.
No third-party packages (including Vue) should
be bundled in. Rather, it’s desirable to have the dependent npm
packages added to a project when the component is added and after npm i.
The compiled css bundle should be included with the package but
should be referenced separately within a project when it’s needed.
The raw scss files that make up the component styles should be
included with the package so they can be bundled into a project’s
existing scss during a build.
I’ve looked into vue-cli-service build --target lib to accomplish this, but it seems that it bundles and packs everything up.
Is what I’m asking even possible? Is it an anti-pattern? Are there alternatives? I don’t know where to begin.
You've headed in the right direction with vue-cli-service build --target lib this is exactly what you need. It bundles your entry .vue file as a component then this bundle becomes your entry point for package.json. It doesn't include the Vue library in it (this is stated in the docs) and I think that by default it's configured to extract the CSS in a separate file in dist folder.
I hope this helps.
we are in the process of uplifting parts of a huge code base. We are bringing in a module which has been built with webpack. In order to avoid code duplication we have used webpacks externals option.
When we start to integrate our module into the main codebase which is currently using browserify, we have an issue where a shared dependency is included twice and causes issues.
Is there are a way to have webpack use the packaged version of the dependency? So in the final browserified bundle we just have the dependency included once?
It seems to me like this may not be possible, if so I will push for moving the rest of our codebase onto webpack (it is underway already).
The only solution I have come up with so far is to have the webpack module also export the shared dependency, and then have the main app use that export, but this is not ideal.
I have ensured that the dependency in both node_modules folders are at the same version and I still get 2 instances.
I need to be able to tell Browserify to only resolve my apps node_modules, or tell it to resolve from top to bottom, i.e. look in the top level node_modules first, is this possible?
I have tried setting the NODE_PATH option when using the cli to no affect.
** update **
So the issue is that when Browserify hits the require() statement in the webpack bundle it resolves from the local node_modules folder, so we end up with 2 instances of the dependency. I can fix this by using a relative path in either the apps require() or webpacks external option and ensuring they use the same file.
So it seems the issue was caused by the fact that I had symlinked (with npm link), the module as I was working on this also. It seems that when Browserify resolves the require in the symlinked module it resolves to its own node_modules, and we end up with 2 copies.
When I install the module normally it all works fine, so this is OK as other consumers of the module should have no issues. It is annoying that it behaves this way, but I just need to ensure that I point at the same dependency in my main app when developing alongside the module.
So my require statement in the main app (while symlinking) looks something like this:
require('./node_modules/my-module/node_modules/shared-dependency/index.js');
I can require as normal when not symlinking.
I'm building node/Express application and want to utilize 'latest and greatest':
node/Express + TypeScript + webpack.
Question: What are the benefits of using webpack to bundle all my nodejs code into one file? Just trying to understand if it is an overkill to use webpack for such purpose.
I think the biggest win you will get with Webpack would be Hot Module Replacement (HMR).
During development, if you were to use a tool like nodemon to watch for file changes you would have to wait for a full restart of your node application, whereas with Webpack HMR it will only update what is changed speeding up your development process. The upfront costs of setting up Webpack definitely payoff over the course of development.
Webpack also gives you the ability to use loaders. In your case using TypeScript you would likely want to use the ts-loader to transpile your code into standard javascript code that is compatible in your node environment.
Good that you're using the good combination of languages at the server-side.
First of all understand why should we use Webpack.
Webpack is used for module bundling by the builds we’re generating. As a best practice, we should not run the source directly.
Also, there two common modes available by default in webpack are,
Development
Production
Development build produces source map files and it’s not minified and uglified. It holds the information about the source files and even it is compressed and compiled it is easy to debug the development build.
FYI, my development build file size is just ~51KB since I use mongoDB in my stack.
Production build compresses our source code into a minimized single file but performs the same task as source code does. It won’t produce source map files and it’s uglified and minified so the debugging is not possible. My prod build file size is just ~9KB.
Notice the size difference after the file compression from dev to prod.
So, I recommend to use webpack not only for bundling, also we can configure transpiler options using loaders in it.
Note: Webpack can be used for both Client and Server side.
Happy Coding!
I have a common module in an angular 2 application. This is how the project is structured:
main
--app
/common
--config
//.ts configs for modules
--services
//angular services
--models
--store
//ngrx store
/component1
/component2
app.module.ts
main.ts
--js
//systemjs dependencies
Gruntfile.js
package.json
tconfig.json
The project is configured to transpile to bundle.js and works as expected. However, now I want to bundle out the contents of common folder and package it in isolation. Such that, I can just load its dependency using system js, and then include it is app.module.ts to use in components.
I need help in getting started, is it some gruntfile/tsconfig changes that I need to make? Or would I have to create a separate package.json/index.ts to transpile .ts dependencies?
The feature I believe you are looking for is the Bundle Arithmetic feature of the systemjs-builder. It is built into SystemJS and works very well.
However, it will mean using SystemJS to bundle your app instead of a grunt.
This has many advantages and actually simplifies many scenarios, like your specific use case, but it may take you a little while to get everything set up.
TypeScript does not support splitting bundles at this time.
Splitting your app into multiple npm packages is not necessary and will introduce significant complexity into development process if your application is small.
My browserify project is dependent on another browserify bundle, which uses standalone bundling. According to docs (on jquery example) I'm supposed to include it as a separate file. But I'd like to have my project in single file (as are my automatisation tools set up at the mooment). If I don't exclude it, my browserify fails to build as it complains about requires to nonexistant paths within dependency.
Is there a simple way to incorporate standalone build into my bundle?
Project I'm dependent on is Matterjs (link to this specific build)
Found it! Add this to your browserify config:
{
noParse: [require.resolve('matter-js')]
}