I have an Angular app where I use browserify to manage my dependencies. I am also using momentjs to do all my time manipulation. I have several modules that I am using browserify to build, but it is pulling in momentjs more than once, even when I use the external command. Here is my code. First I have a base module that has all of my shared libs:
require('angular');
require('angular-route');
require('moment');
Here is the code I use to browserify in my gulpfile.js:
browserify().require('./js/donor/donor-libs.js')
.bundle()
.pipe(source('donor-libs.js'))
.pipe(gulp.dest('./build'));
This builds out fine and has the libs that I would expect including momentjs.
Now I go to build a module that is dependent on this module. momentjs is used in this module. Here is the code that I use to build the module:
browserify().require('./js/donor/history-module.js')
.external('./js/donor/donor-libs.js')
.bundle()
.pipe(source(filename))
.pipe(gulp.dest('./build'));
Now when I look in my build directory, I have momentjs in both the donor-libs.js and my history-module.js. Why doesn't it recognize that I have already required in momentjs in my donor-libs.js? What do I need to do to only require in 3rd party libs one time? What don't I understand about the external command?
The reason libs are being pulled in multiple times is that the external command is being used improperly. external is expecting a path or an array of paths that will externalized. external will not look through a js file and find the required files and then not pull them in other modules. The code should of looked something like this
.external('angular', 'angular-route', 'moment')
or the path to the required lib. This would of externalized these files and fixed the problem of a lib being pulled in multiple times.
Related
I have a program with multiple .vue files in src/components. These use typescript and sass. The program uses webpack for compilation and bundling. I would like to add all these components to a single npm package to be used as a library with the following restrictions:
It should be compiled down to javascript and css so whoever imports my library doesn't need my compile dependencies and webpack configuration
The components depend on typescript files. These should also be compiled, but not bundled. They are valid entry points for the library.
The import for the users of the library should be as painless as possible. It would be optimal if the generated js and css could be loaded in a single import, just like importing a .vue file
Is this possible to do? And if so, how? If not, how could I best approximate this or what are my alternatives?
I have tried to use vue-cli-service build --target lib but it seems that can only handle one component, bundles the ts files, and I'm not sure if it behaves like I expect when you import a file.
I'm trying to build a library (mostly some .vue components) to reuse in different projects (no public npm) with vue-cli-service. Apparently everything its already setup, and I can confirm that the build is fine (js, and css). However, I'm unable to use it in a separate project as an external module because it uses the spread operator (and probably more ES20XX features no yet parsed).
Module parse failed: Unexpected token (2683:8)
You may need an appropriate loader to handle this file type.
| params() {
| const queryParams = {
| ...this.filters,
| ...this.sorting,
| ...this.config.params,
This is the standard command I'm using to build the library
vue-cli-service build --target lib --name [mylibname] ./src/components/index.js
By default the bundle should be already polyfilled but it seems to me that it's not the case.
I've read that I might change the webpack configuration on the project I'm using into, but I'm against parsing the whole node_module folder and also I would love to just have the simplest workflow possible (like import a module and its css).
So my question is, how to polyfill my bundle to be perfectly usable in no matter what Vue project without any hassle ?
Ok, it seems that reinitializing the project with vue-cli without typescript and with separated configuration files instead of into package.json was a good idea, as now is transpiled as needed.
var queryParams = _objectSpread({}, this.filters, {}, this.sorting, {}, this.config.params);
Unfortunately the hidden configuration of vue-cli webpack can't help to see what has changed.
I was of the understanding that Browserify could be used to bundle various JavaScript files into one. However, after looking at some examples on the internet, I found that some people use Browserify and yet they also include gulp-concat.
For example, the angularjs-gulp-example project uses both.
Why? I thought Browserify could do the concatenation as well.
Browserify is a bundler that creates JavaScript bundles from CommonJS modules. Typically, the bundle will contain all of a project's source files and all of the CommonJS/UMD dependencies. (Also, like Node, Browserify can require JSON files, so they could be in the bundle, too.)
If a project has dependencies that are not included using require and are instead indended to be used in <script> elements - the build process might opt to use a tool like gulp-concat to concatenate them to the front of the bundle.
That's likely why gulp-concat is used in the project you referenced in your question. It concatenates an Angular template cache that's generated from .html files - something Browserify doesn't deal with (unless a transform has been configured).
When I download a package in bower or npm, many irrelevant/not-useful files also
get included especially in npm packages. I generally only include .css or .js files of that package for e.g. in bootstrap e.t.c. But for package like polymer or Anjular.js or Electron we need multiple other file too. So when I deploy my project should I include the complete folder or just copy the required files separately or is there any other approach ?
When you deploy to your production server, a good approach would be to only include the files you are actually using. You should also create an optimized file to serve to the client.
To achieve that, you normally have a deploy script that generates one or more minified .css or .js files (for example, vendor.js for libraries and bundle.js for your code).
This script can be build with tools like grunt, gulp or you can use a module bundler like Webpack or Jspm.
You can create your own Grunt or Gulp script like the ones in this website.
When using a module bundler and modern javascript to organize your code, you'll build, for example, an entry javascript file (bundle.js) that will look like
import {MyLibrary} from 'my-library';
import {AnOtherLibrary} from 'an-other-library';
console.log(MyLibrary.saySomething());
In this case, Webpack handles the node_modules imports and the creation / minification / concatenation of the production version of .js files.
As you said, there are multiple files to be included (js, css or even fonts) so configuring your scripts may take some time. Try finding a Yeoman generator that uses your frameworks, and use the deploy scripts others already created for this purpose. This one uses AngularJS, Bower and Grunt. This one uses Webpack and ReactJS.
I would like to ask what is the purpose of using browserify with noparse option set to true (or how browserify works). For instance:
if browserify does not parse files at all, does it means that it will not find require statements?
if it does not find require statements, then how to force code to load module? For instance, I have toastr & jQuery. toastr requires jQuery. But when I used browserify to create a bundle with noparse set to true, and I added to this bundle both files:
var bundler = browserify();
bundler.add('jquery.js');
bundler.add('toastr.js');
bundler.bundle();
then I get the error, that jQuery module it not found.
Normally when you bundle a file with browserify, it parses the file for require() calls so it can build a dependency graph and bundle the required files. The purpose of the noParse option is to skip that parsing when you don't need or want it. For example, if you're bundling a large library file like jQuery and you know it doesn't contain any require() calls that need to be processed, it will save time in bundling if you noParse that file. Also, it's currently difficult to require() a previously browserified bundle when making a new bundle. In that case you can sometimes resolve the issue by setting noParse for the previously browserified bundle.
if browserify does not parse files at all, does it means that it will not find require statements?
Yes.