Provide a way to build standalone bundles without UMD
See original GitHub issueCurrently the --standalone
flag wraps the whole code in a silly UMD wrapper. This isn’t really helpful if you just want the standalone to register it self always as global. There should be away to turn UMD off, or provide your own template instead.
Issue Analytics
- State:
- Created 9 years ago
- Reactions:2
- Comments:10
Top Results From Across the Web
Standalone Builds - SurviveJS
To make a bundle for your own library, you need to use a bundler, such as webpack, Rollup, or Parcel. How Bundlers Work#....
Read more >angular2 how to bundle a UMD module without ng2 ...
Step 2: Use rollup to create UMD bundle. const pkg = require('./package.json') const rollup = require('rollup'); gulp.task('rollup:module', ...
Read more >A way to build Angular plugin with AOT and standalone deploy
In this article i will show you how to build angular UMD plugin with AOT (Ahead-of-Time) support and standalone deploy.
Read more >Standalone Browserify Builds - Forbes Lindesay
Browserify now supports standalone builds thanks to integration with my umd (universal module definition) library.
Read more >JavaScript Data Grid: Building Applications With AG ... - AG Grid
If however you do not need all the features provided by either package (Community or Enterprise) then it's possible to create your own...
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
Hey @jstayton - sure thing.
All Browserify bundles are defined within a wrapping closure so nothing in your bundle will leak out. The issue is that JavaScript doesn’t currently provide a good way to keep global variables from “leaking in”. In other words, your code and bundled dependencies can reference global variables that someone else defined.
Imagine that your script is deployed to a site that’s already using AMD. AMD defines a global
define
function. No problem - that shouldn’t affect your code. Now imagine that your code includes a UMD dependency that goes looking for the existence ofdefine
to decide whether it should behave as an AMD or CommonJS script. Now you have a problem, since your dependency will convert itself to AMD in this environment.Ideally JavaScript would provide a way for a closure to “whitelist” which global variables it could access -
window
for example. Since this feature doesn’t exist, we instead need to blacklist the global variables the closure doesn’t want access to by redefining them within the closure.When (and only when) you use the
--standalone
flag, Browserify does exactly this fordefine
,module
, andexports
.@3rd-Eden, you can achieve your desired behavior today using the https://github.com/primus/deumdify plugin. It’s a hack, but a useful and well-maintained one. 😃