Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Stop using AMD modules, use browserify/webpack/commonjs-everywhere instead #67

duncanbeevers opened this Issue Jun 28, 2013 · 5 comments


None yet
4 participants

duncanbeevers commented Jun 28, 2013


sokra commented Jun 28, 2013

You can easily generate one out of the existing files

npm install webpack -g
webpack lib/source-map/source-map-consumer.js --output-library SourceMap --optimize-minimize source-map-consumer.js

This bundles the SourceMapConsumer, with the result:

Hash: 3e1762862d2c6cb3351d
Version: webpack 0.11.0-beta5
Time: 661ms
                 Asset  Size  Chunks             Chunk Names
source-map-consumer.js  7572       0  [emitted]  main
   [0] ./lib/source-map/source-map-consumer.js 16038 {0} [built]
   [1] ./lib/source-map/util.js 2950 {0} [built]
   [2] ./lib/source-map/binary-search.js 3204 {0} [built]
   [3] ./lib/source-map/array-set.js 2630 {0} [built]
   [4] ./lib/source-map/base64-vlq.js 4892 {0} [built]
   [5] ./lib/source-map/base64.js 1137 {0} [built]

And you can use it in your javascript:

<script src="source-map-consumer.js"></script>
  var consumer = new SourceMap.SourceMapConsumer(rawSourceMap);

duncanbeevers commented Jun 28, 2013

My goal is to load the SourceMapConsumer through a browserify require. I'd like to continue to use npm/package.json to handle dependencies rather than creating a custom build of one script.

It should be straight-forward to create two new modules and have source-maps depend on them.

Does it seem useful to have these two tools (SourceMapGenerator and SourceMapConsumer) available individually?


sokra commented Jun 28, 2013

Theoretically you could require inside a module with browserify:

var SourceMapConsumer = require("source-map/lib/source-map/source-map-consumer");

But sadly browserify do not accept the define style source-map is using...

This could be solved by a browserify source transform: deAMDify

Maybe you need to additionally ignore amdefine...


michaelficarra commented Jun 28, 2013

Does it seem useful to have these two tools (SourceMapGenerator and SourceMapConsumer) available individually?

I think so.


fitzgen commented Jun 28, 2013

I'm not going to split this into two different npm modules because it adds maintenance overhead. On top of that, since they both depend on a few of the other files in this repo, I would have to duplicate them to each module and your browserify build would still end up with a bunch of extra code (in this case duplicated rather than unused, but why go through the effort at this point?)

As @sokra says, you would be able to require individual pieces of the library and have browserify do the Right Thing(tm) if we weren't using AMD.

I'm open to switching to normal common js style requires, but this library also needs to work inside Firefox and the greater web. I've been using AMD because it has been easiest (more like least difficult) to make the library work with web, node, and Firefox environments. I'm ok with telling people browserify (or webpack, or whatever) is the way to use this lib on the web. Also, Firefox devtools recently landed a common js loader. I've filed a bug to switch from this build process to using the loader and just including this lib's directory structure into Firefox as is.


In order to lose the AMD stuff, we also have to fix that bug. I don't have the cycles currently, but if someone wants to step up and do both of these things, I'd be more than willing to land this stuff, and everyone can be happy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment