On these days, a good approach to obtain a great performance in SPA application is prepare a gzipped client side bundle from a few gulp tasks.
Based on these, an awful approach to debug is consider the use of a full bundle unminified # dev environment. The question is about possible of use a gulp browserify task and gulp inject to unroll the client bundle in separated files like was developed.
I mean, maybe would be possible inject a bundle or a couple of files with a browserify boilerplate to resolve a bunch of require's and module.exports statements.
Thoughts?
The correct answer is use an option that gulp-browserify provides to run a complete src tree instead use a bundle. just set a optional flag debug: true as follows, in example:
gulp.src('./app/js/app.js'). // this path is the entry point
pipe(browserify({
insertGlobals: true,
debug: true
}));
Related
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.
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
}
The gulpfile.js I wrote is Common gulpfile.js.
In a build task, inject should inject all static files into html outputs, but it inject nothing in the clean build , I must run same command(here is gulp -p project build) twice(gulp -p project build && gulp -p project build) to inject them successful.
I have tried use run-sequence, it helps nothing.
Is this a bug?
Thanks :)
Your gulp tasks appear not to be returning their streams. If you do not return a stream from a task, then any other tasks that depend on it will not wait for the async behaviour to complete before running.
So more or less, what you're seeing is that you have two levels of things that have to happen: first your "script", "style", and "asset" tasks need to be completed, and then when everything's ready your "view" task can do its work. The first time you run it, all four tasks are run at nearly the same time (so "view" runs with old "asset" results, etc.)
To fix it, just return the working stream in each task:
gulp.task('style', ['check'], function () {
var less_filter = gulpFilter('**/*.less');
return gulp.src(path_current.src_path_style)
.pipe(less_filter)
// ... the rest of your pipes
.pipe(browserSync.reload({stream:true}));
});
I have two requirements for my build script:
When I run gulp clean build, clean must complete before build
starts.
If I run gulp build, then clean shouldn't run.
So, if clean is specified, then build should wait for it, else start.
The first part is possible if I do
gulp.task('clean');
gulp.task('build', ['clean']);
However, that violates point 2
If I do
gulp.task('clean');
gulp.task('build');
That violates point 1
Is this possible with gulp?
You cannot run two gulp tasks with the same command like you did with dependency management you want.
Anyway you can pass an argument to your build task that will allow, using a little ternary, to wait for the clean one to complete before running.
So something like this:
gulp.task('build', (process.argv[3] === '--clean') ? ['clean'] : null, function () {
...
});
This way, you can launch your build normally with
gulp build
And when you want to call it with the clean:
gulp build --clean
There is a lot of ways to get better argument handling, like yargs or the env of gulp-util. But I found my method nice in the fact that it doesn't need any extra dependency.
Looks like you can use Gulp-If
gulp.task('build', function() {
gulp.src('*.*')
.pipe(gulpif(condition, clean()))
.pipe(gulp.dest('./dist'));
});