How to retrieve Browserify options from a plugin?
See original GitHub issueThe _options
property of the browserify instance passed as parameter to the plugin is protected - as per naming convention and the TypeScript definition.
How are plugins supposed to get the options of the Browserify instance?
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (3 by maintainers)
Top Results From Across the Web
Browserify
Bundle up your first module ; Install the uniq module with npm: ; Now recursively bundle up all the required modules starting at...
Read more >Readme - browserify - Read the Docs
Usage: browserify [entry files] {OPTIONS} Standard Options: --outfile, -o Write the browserify bundle to this file. If unspecified, browserify prints to stdout.
Read more >how to build modular applications with browserify - GitHub
introduction. This document covers how to use browserify to build modular applications. cc-by-3.0. browserify is a tool for compiling node-flavored commonjs ...
Read more >Browserify - order of transforms/plugins - Stack Overflow
@VladimirRovensky, the plugins are registered to the browserify instance directly, so there is register order.
Read more >Browserify - npm
Start using browserify in your project by running `npm i browserify`. There are 3186 other projects in the npm registry using browserify.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I would say this means that it was de jure private, but is de facto public since that is how it is treated in the wild 😃
The
_
properties in browserify were probably intended as a marker of privacy, but_options
,_bpack
and other underscored properties are now vital to the functioning of the ecosystem. Whatever the original intent was no longer matters. Because of this precedent, we won’t change it unless there is a very good reason to intentionally break all those users. It is just as safe to rely on._options
as it is to rely on.plugin()
.I totally agree with you, especially this part:
I think though that this reality of things should be documented. As you say, it is vital to the ecosystem but right now, and if I’m not mistaken (maybe it is documented and I missed it), it only relies on word of mouth. When I started working on my own plugins, I had no idea of the existence of these properties or what they contained exactly.
I also think that this reality should be reflected by the TypeScript definitions, although I know this is not the responsibility of the maintainers of Browserify to update those definitions. About that, I’d like to update them (and add some sugar like a definition for Plugin and Transform), and I will, now that I’m sure that
_options
should definitely be considered as public.