search

elidoran / cosmos-browserify

Browserify npm modules for client side in Meteor packages
MIT License
78 stars 12 forks source link

debug=true causes file bloat or allows proper source mapping? #8

Closed elidoran closed 9 years ago

elidoran commented 9 years ago

Contributors of #7 say:

  1. debug should always be true to make source mapping work
  2. debug=true shouldn't cause file bloat in production because Meteor strips out the source map comment

These things make sense to me. However, FlowRouter had an issue with debug=true causing the file to be ~10KB larger.

When I checked before I did notice the file was larger for production when debug=true. I checked recently and the source map Browserify puts in the file is a comment which is removed by Meteor for production. So, what made the file bigger then?

As cosmos:browserify is now it sets debug true except when the build or bundle command are run without the --debug option. I'm going to maintain that behavior for now. It can be overridden with the new per file configuration feature from #7 by placing debug:true in the options file.

To determine the proper behavior:

- [ ] verify source map is broken when debug=false - [ ] verify production files are larger when debug=true

stubailo commented 9 years ago

I think this is something that could be easier to figure out with automated tests. I'll maybe write a test later that runs meteor build and makes sure the source map is stripped.

elidoran commented 9 years ago

As of 0.4.0 debug is always set to true to produce the source map. Then, the source map comment is extracted via the exorcist transform and provided to CompileStep separately. This seems to work well.

Exorcist writes the source map to a file. So, we have to read that file to provide it to CompileStep. It'd be nice if we could get it another way, but, in 0.5.0 I'm leaving the file there (instead of deleting it) as a cached map result. So, it's not so bad.

It would be nicer if browserify returned a result object we could get both the file result and its source map from, similar to the coffeescript compiler.

Also be nice if CompileStep provided the file source as a readable stream we could pipe through transforms and back to a CompileStep writable stream instead of holding each file in memory as a string.