I'm using pdf.js in an angular project. Building with gulp in production mode works fine, but the production build produces non-working code that fails silently without and warnings or errors, whatsoever. I never get a viewer canvas.
It turns out the problem lies not with minification, but rather with concatenation.
The dist directory of the pdfjs-dist bower package contains three files:
pdf.js
pdf.worker.js
pdf.combined.js
the bower.json file list pdf.js and pdf.worker.js, but when using gulp bower copy and concatenation you should use pdf.combined.js instead of the other two. Add an override to your projects bower.json
"overrides": {
"pdfjs-dist": {
"main": [
"build/pdf.combined.js"
]
}
}
Related
Recently I stumbled upon a library for nodejs, that I want to use in a frontend project. Because the whole project is developed in ES6, the library should not be transpiled (we only develop for browsers, supporting es6). Of course, I could "browserify" manually, but because it can be a reoccurring task, I would like to use browserify without babelify or any es6 transpilation process.
If transpilation is needed later on, I'd integrate it into the whole build process, but not beforehand.
Is there any option to browserify to omit es6 to ecmascript-5.1 transpilation?
By default, browserify does not do any transpilation process, if no plugins are enabled. It turned out, that the library I wanted browserify, passed some options to browserify in its package.json:
"browserify": {
"transform": [ [ "babelify", { "presets": "es2015" } ] ]
}
this caused browserify to use the babelify plugin by default.
Migrated existing webpack project to use webpack 3.5.5 and its new config. Using express server instead of webpack-dev-server.
I had to setup the resolve in webpack as below.
const resolve = {
extensions : ['.js'],
modules : [
'node_modules',
'src',
'testApplication'
]
};
When i debug this webpack application using chrome developer tools I can see the 2 versions of source files.
The first one under webpack://
It is exactly matching with the source
The second one under webpack-internal://
This one is the babel compiled version of the source.
My questions are
Is there someway where I get only a first version of the file instead of both?
I thought node_modules should have been implicitly defined as a module rather than me specifying it explicitly in resolve, is there someway that I can make the build work without having the node_modules defined in resolve.
After using the same source code with webpack 3.5.5(migrated it from webpack 1.14.0) the express server start seems to have slowed node. My guess is that having specified the node_modules in modules under resolve has caused it. Any ideas?
You can configure the source maps using Webpack's devtool property. What you want is devtool: 'source-map'(source). This will only show you the original source code under webpack://. Note that there are other options that might be more appropriate for your use case.
["node_modules"] is in the default value for resolve.modules. However, if you specify resolve.modules you need to include "node_modules" in the array. (source).
It seems strange that you specify "src" and "testApplication" in resolve.modules. If you have local source files you should require them using relative paths e.g. require("./local_module"). This should work without having src in resolve.modules
Specifying node_modules in resolve.modules is not responsible for any slow down (see 2.). There are many possible reasons the slow down. E.g. maybe you are erroneously applying babel to the whole node_modules folder?
It seems to be resolved (or at least greatly improved) in Chrome 66.
In a bower.json file, what are the resolution and overrides properties used for?
{
"name": "name",
"dependencies": {
"angular": "~1.4.8",
...
"jquery": "2.2.4"
},
"overrides": {
"ionic": {
"main": [
"release/js/ionic.js",
"release/js/ionic-angular.js"
]
}
},
"resolutions": {
"angular-ui-router": "~0.2.15",
"angular": "~1.5.3"
}
}
Resolution
The resolution section appears when you need to resolve dependency versions (after bower install) when conflicts occur. It's for making a decision regarding which concrete version of a dependency to use when the need to resolve dependency conflicts arises - bower automatically injects this decision as the "resolution" record. So the next time a conflict occurs (when updating the dependency tree, etc), the resolved version will be based on the "resolution" data in your configuration file.
Overrides
Overrides section is used to override the file(s) references when pointing to dependent library.
Task runners in most cases use the bower configuration library metadata to inject links to these libraries into a page's content. When we want to inject a bootstrap link into a page, we do not need to go into the "bower_components" folder, find the package, and investigate the file content. We can use the component metadata to find the main, injectable file reference.
The "overrides" section is used to change this data to use another file, or even a set of files, as a package's main entry point.
Multiple Bower packages can list different versions of the same library as a dependency. The resolutions section specifies which version of the library to use whenever this type of situation occurs. If not specified in bower.json, you will receive a command line prompt upon running bower install.
The overrides section makes it possible to override default paths to assets installed through Bower when using a task runner like Gulp. If you intend to move files from their default location in the bower_components folder to accommodate your build process, for example, it could prove handy in this type of setup.
We use resolutions object in your bower.json file to specify the component name & version to automatically resolve the conflict when running bower commands.
Overrides section is used to override the file(s) references when pointing to dependent library.
I'm trying to figure out if it is worthwhile moving to webpack, I am leaning towards saying no - figuring I have more important stuff to do - but I would like to see some practical examples of how to make webpack work.
So if I have the following Gulp.js task how would I do them as a webpack task?
gulp.task('subpaths', ['clean_subpaths'],function() {
//Minify and copy all JavaScript (except vendor scripts)
gulp.src(paths.subpath_scripts)
.pipe(fileinclude({
prefix: '##',
basepath: '#file'
}))
.pipe(contextswitch())
.pipe(uglify())
.pipe(strip())
.pipe(rename(function (path) {
path.basename += timestamp;
}))
.pipe(gulp.dest('public/longcache/javascripts/subpath'));
});
So the tasks above do -
include files inside of other files for processing.
run the piped content through my own defined code - I guess in webpack
that would be run my own plugin?
uglify
remove console statements
rename the output file so it has a version.
write out to a specific location
The first item -- include files inside of other files -- is one of webpack's biggest benefits, speaking as someone coming from an all grunt/gulp workflow. Instead of managing dependencies externally (in your build tools), and having to ensure that files are combined correctly based on their runtime dependencies, with webpack your dependencies are part of the codebase, as require() expressions. You write your app as a collection of js modules and each module loads the modules it relies on; webpack understands those dependencies and bundles accordingly. If you're not already writing your js in a modular fashion, it's a big shift, but worth the effort. This is also a reflection of what webpack is meant for -- it's conceptually oriented around building a js application, not bundling some js that your site uses.
Your second item would more likely be a custom loader, which is easier to write than a custom plugin. Webpack is very extendable, throughout, but writing custom integrations is poorly documented.
Webpack's Uglify plugin will also remove console.logs, super easy.
Specifying output details is part of your basic webpack config, just a couple of options to fill in.
I have just started using Webpack via a recommendation and am looking for some guidance on how it should be implemented for build and deploy purposes.
I currently have it up and running nicely using webpack-dev-server and some Gulp tasks.
Traditionally I would use Gulp or Grunt to concat files among other things and then use the task runner to copy all my files and assets to a dist or build directory from where I would deploy everything.
At the minute, Webpack does it's thing and builds the bundle file, images etc and then copies them to the build dir, using the [hash].js naming convention.
So my question is, what is the standard practice for then copying over my index.html file and then correctly linking it to the js file to be used in production.
Unless I am completely misunderstanding how Webpack should be used, should there not be some way for me to do this, with the ultimate outcome being me having the ability to navigate to the build dir and see my app up and running as it should be?
I am currently using a plugin to move my index.html. Make sure your webpack.output.publicPath points to your site so it can link images and other resources.
var CopyWebpackPlugin = require('copy-webpack-plugin');
var webpack_config = {
//Other configs here
output: {
publicPath: 'http://localhost/'
},
//Other configs here
plugins:[
new CopyWebpackPlugin([
{from: './index.html', to: './index.html'},
], {
ignore: [
'*.txt',
{glob: '**/*', dot: true}
]
})
],
//Other configs here
}