browserify adding not required files to build - browserify

Browserify works by walking the require statements building up a dependency tree. My problem is, that I would like to include some other files, that are not required anywhere. Those files would set some global variables, when I build for testing, and I would omit them from production builds.
Is there some option in browserify to achive this?

Add them as entry files:
browserify({entries: ['one', 'two', 'three']})
// or
browserify()
.add('one')
.add('two')
.add('three')

Related

Include package.json dependencies from another file

The Webpack/Vue ecosystem is a very fragile one, with minor updates to loaders regularly breaking the build. It's basically a dedicated job to curate a working Webpack config together with a list of the exact dependency versions that are needed to make it work.
This Webpack config can easily be kept in a repository and then copied to many different projects and imported in their local webpack.config.js because webpack.config.js is just Javascript.
I'd like to do the same thing with package.json, i.e. have the curated list of dependencies in a separate file and when running npm install have them added to any other dependencies a project might have.
Do npm or yarn or any other external tools offer such a functionality?
Are you specifically trying to use a js file? If so, I don't have an answer, but if json is enough, you can just make an node package that just has the dependencies you want in it. Someone that includes your package will then pull in all the dependencies listed in your package because npm pulls in the dependencies of a project's dependencies.
Also see https://stackoverflow.com/a/55483109/14144258

How to print all dependencies in meson?

I checked out a gtk project inside a docker and during meson build found many dependencies are missing eg. libwayland-dev, libxrandr-dev...
Because meson fails at the first missing dependency, I had to redo this over and over to get install the entire list of dependencies that will be looked for using pkg-config. And, in projects with multiple git submodules, this becomes a lengthy process.
Wondering if I'm doing this whole thing wrong or if there is a way to get to the complete list of dependencies.
To get dependencies for your project, from build directory run:
meson introspect --dependencies

How to handle chained dependencies in Sass projects with npm?

I have two Sass projects which I'm working on. Let's call them ProjectBase and ProjectExtended. ProjectExtended depends on ProjectBase, and the ProjectBase depends on a third party node module, namely Bootstrap.
ProjectBase should be independent but also work when used as a dependency.
ProjectBase has this include in it's Sass file:
#import '../node_modules/bootstrap/scss/bootstrap';
ProjectExtended then has this include:
#import '../node_modules/ProjectBase/scss/ProjectBase';
ProjectBase can build this without issues after running npm install because the included file is in that path under node_modules.
The problem arises in ProjectExtended because now after running npm install, the Bootstrap source is not in the same relative location anymore from the point of view of ProjectBase:
-node_modules/
|--bootstrap
|--ProjectBase
As you see in this case Bootstrap is suddenly a sibling instead of a dependency like so:
-node_modules/
|--bootstrap
|--ProjectBase
|--node_modules
|--bootstrap
As a workaround, I manually go into node_modules/ProjectBase and then run npm install in there, which installs those dependencies a second time under that folder.
Is there a better way to handle this?
This problem can be solved by providing custom importer to node-sass. I have simple implementation of such importer that you can try to use, it will allow you to configure all necessary paths and rules to resolve imports inside your .scss files.
In your case configuration may look like {roots: ['node_modules','../node_modules']} if I understand your directories structure properly.

Why doesn't Yarn install all executables in .bin folder?

I've just started using the Yarn package manager and I downloaded a starter Ionic 2 project.
In this project, we have a lot of help from scripts that compile, minify, lint and bundle our code. All of this is provided by ionic-app-scripts, which has several dependencies which it uses to run commands.
The problem is when I use Yarn to install, the node_modules/.bin/ folder does not contain all the necessary executables, like tslint, which is a dependency of ionic-app-scripts, so it is not directly in my package.json.
The result is that when I use Yarn, ionic-app-scripts doesn't work because it expects that the .bin folder contains a tslint executable!
What can I do? Are the ionic-app-scripts's definitions a problem?
[note]: npm install works, but Yarn is much faster!
This is a known issue, and there's a pull request with more information.
In short, if you want to fix this now, you'll have to explicitly include the packages from which you need binaries in your dependencies.
I had this issue but a different solution.
The solution was from this ticket https://github.com/yarnpkg/yarn/issues/992#issuecomment-318996260
... my workaround is going to file manager, right click on /node_modules main folder, selecting properties, and check-uncheck "read-only". You can do it also using attrib in command line. Then you retry installation and it works.

Browserify - How to include non-public purchased third party scripts

I am new to browserify and its usage is not completely clear to me although the benefits seem to be compelling.
I have a couple of questions and was hoping someone could clarify.
I've seen blog posts about using browserify-shim in the package.json to include third party libraries like jquery and bootstrap. I've also seen posts where tools like gulp are used generate the bundle file. I can't seem to find a good answer on why browserify-shim is required if tools like gulp are able to automate the process. Can someone please shed some light? Why is browserify-shim even required? I feel the gulp solution is a little cleaner although a little more involved. It won't pollute package.json with browserify specific stuff that is a build thing and therefore goes together with gulp (just my personal opinion)
How does one deal with third party libraries that are not in npm and also not public? For example, we purchase a script from a third party. That script is not any common js, but is a regular js file with some dependencies (example, on jquery and underscore).
Browserify lets you take the world of Node and bundle it up for delivery to a browser. It understands Node modules, which define dependencies via CommonJS require statements.
But what if you have some JS code or library that is not defined as a Node module and does not support CommonJS? Enter browserify-shim. It provides a shim wrapper around any script, like your private third party script, so that it can be defined as and used as a Node module that Browserify understands.
The use of browserify-shim is completely orthogonal to how you execute Browserify. There are basically two options there: A) Use Browserify's command line API or B) Use Browserify's JS API.
Using a build tool, like Gulp, implies the second option, since you'd use Browserify's JS API in your Gulp build script (i.e. gulpfile.js). A lot of people prefer the use of Gulp because it has a good ecosystem of plugins that allow you to do a lot more than just call Browserify (e.g. compile CoffeeScript, compile SASS, run JSHint, etc).
So, to answer your specific questions:
Browserify-shim is only required if you have JS code that is not written as a Node/CommonJS module that you need to bundle via Browserify. To do so, you will need to tell browserify-shim which files to shim as modules (and what dependencies they have) in package.json. Note that this is totally unrelated to Gulp; so you will need it whether you use Gulp or not.
What you describe is the perfect use-case of browserify-shim. Put your third party script(s) in your project, configure the files to be modules in package.json per b-shim's documentation, require them in your code, and execute Browserify to bundle them up with your code. You could also bundle them up separately, put them in their own project, etc - however you want to structure it.
A couple things to note:
You can shim just about any JS library this way.
Shimming a JS library to be a Node module changes global scope to be private scope. Hopefully everything in the library is namespaced so that all of its functionality can be exported as a single module, but if it's not, you might have to modify the shimmed code to explicitly attach things to window (which is easy but not recommended) or split the code up into separate files/modules.
Both Browserify and Gulp use streams in their JS API, but Browserify uses native Node streams while Gulp uses Vinyl streams. Since they don't play well together, you'll probably have to use vinyl-source-stream to adapt Gulp to Browserify (e.g. for renaming files in a Browserify pipeline), or use vinyl-transform to adapt Browserify to Gulp (e.g. wrap a Browserify stream for use in a Gulp pipeline).