Require.js compiler generates inaccurate sourcemaps - requirejs

I'm using require.js's build tool (through grunt-contrib-requirejs) to pack up all my code into a minified version, and I've turned on generateSourceMaps.
However, the sourcemaps require is generating are wrong. In some files, they're fine, in others they're off by a line or two; in some, they're off by as many as 17 lines. What could be going wrong?
Possibly weird things about my repo:
handlebars templates integrated into the build (they're precompiled, using Alex Sexton's plugin)
a number of shimmed files that don't include require code standard (cordova, backbone, marionette).
I am using r.js to concatenate files, but not to minify them. Minifying the files doesn't fix the problem (the same line errors occur).
in some configurations, r.js gives an error that says it cannot generate source maps if preserveLicenseComments is on. In others (when not minifying), it seems to have no problem keeping license comments. Either way, turning it off does not help correct the line numbers.
files that are listed later in the sourcemap header seem to have larger errors
What could be causing this, and how can I fix it?
UPDATE
I've narrowed this down some: the sourcemap generator is losing a line every time it hits a line like this:
console.log('l170'); // logs as on line 170
//>>excludeStart('excludeHbsParser', pragmas.excludeHbsParser)
console.log('l172'); // logs as on line 171
I'm not precisely sure what the r.js parser is doing with these lines, but it does not seem to be accounting for them properly in the sourcemap generation.

Adding to r.js config:
skipPragmas:true
Did the trick for me, not sure if this will help everyone.
https://github.com/requirejs/r.js/blob/2.2.0/build/example.build.js#L299

Related

Configure haskell-language-server to see generated proto-lens modules

I've got a fairly stock stack based project that uses proto-lens-setup to generate some Haskell code from some .proto files. I'm using haskell-language-server with wonderful success in emacs for everything except when my code imports any of the Proto.Myproto modules. It can't find them and thusly can't properly check the files I'm editing.
The project builds perfectly, but I'd like to have the lsp working. It's very helpful!
I get errors highlighted anytime my code uses an identifier from the proto-lens-generated code. I've tried looking into hie-bios configurations but didn't see anything obvious to put in a manual config to make it work. I don't normally have a manual hie-bios config.

How to use webpack components

Due to the lack of support of modules or packages under development in npm I have decided to use webpack's components which from the look of the example provided here webpack/examples/components seems to be exactly what I am looking for. However there is no example how to actually use the example. Drawing from webpack's convention I thought that:
webpack/examples/components> webpack component.json > bundle.js
would do the trick but nope I get an error. Tried some other stuff like putting an entry file and an output file in the webpack.config.js but no luck there either. Has someone ever use it, does it work and most importantly how to start it?

Debug concat/minified files with Grunt

I'm using grunt concat/uglify to reduce the number of calls being made to load JavaScript.
I removed all the hard-coded links to the actual javascript files, and now reference the one javascript file produced by grunt.
how can I continue to debug/view my javascript in my development environment?
Is that what source maps are?
i.e.
https://www.npmjs.org/package/grunt-concat-sourcemap
Yes. You will need to generate a sourcemap to continue debugging your code easily.
There are two types of sourcemap, but the sourcemaps need to be maintained through each transition. SO if you concat in one step an minify in a second step, the minify process needs to know that the concat step generated a sourcemap and generate it's own sourcemap based on that sourcemap, so that the minified code sourcemap corresponds to the original input, not the input from the concat step.
There are several ways around this -- the easiest way is to just not minify in your test/deveopment environment. There are also minifiers that will do the sourcemapping correctly for you, but they can be hard to configure.
You might also want to take a look at browserify -- this is a tool that lets you write your front-end browser code like it was node modules, and it will concat and generate sourcemaps for you!
Alternatively you can also just rely on gzip compression from your server and run your code through a minifier -- this works surprisingly well.

How use dev and prod assets in NodeJS/Express/Jade properly

I have a NodeJS application with Express based structure and Jade module for a views. I need to use a full version my assets on a developer machine and min version in production machine.
Can you explain best practices of how should I do it properly?
EDIT: If you put a minus please describe the reason.
Not sure why there isn't an "official" way of doing this (compared to what Ruby on Rails does).
Here are a few suggestions:
DIY
Here's what I've been doing so far:
At server startup, I run uglify-js on all the js files (under .../js, and create the minified version under .../min) with something like so (leaving out the reading/writing of the files):
var jsp = require('uglify-js').parser;
var pro = require('uglify-js').uglify;
var ast = jsp.parse(code.toString('utf8')); // parse code and get the initial AST
ast = pro.ast_mangle(ast); // get a new AST with mangled names
ast = pro.ast_squeeze(ast); // get an AST with compression optimizations
var final_code = pro.gen_code(ast); // compressed code here
then in html templates, based on some environment variable to trigger production environment, I generate the path for the <script> tags to either point to .../js or .../min.
This leaves out quite a lot (where you would group all js files into one minimized one to reduce the number of browser queries and such), but hopefully this can help you craft your own strategy.
Piler
That said, I've been meaning to try piler (https://github.com/epeli/piler), which seems to be a better alternative to the DYI way.
Using Grunt
Grunt.js (http://gruntjs.com/) is also quite suitable to help preprocess files (html, js, css, ...)
Here are a few pointers:
grunt-recess: https://github.com/sindresorhus/grunt-recess (especially interesting if you use less)
how to config grunt.js to minify files separately
Grunt tasks to process HTML files and produce a deploy directory of optimized files (https://gist.github.com/necolas/3024891)
I view minification as a build step and prefer to not burden the application at runtime with it. Therefore, I would setup my HTML files to refer to file paths which are generated from the build tool and then use the build tool to figure out whether or not to minify.
I haven't actually needed to make it conditional myself because I haven't needed to have unminified code in the browser. With grunt setup to watch the source files and recompile automatically, I can edit a JavaScript source file and it automatically gets rebuilt and placed into the appropriate runtime location. However, I could see this being useful for stepping through code. IE 9 has a formatter in its dev console which is useful for debugging minified code, but I'm not sure how common that is across browsers.
If I were to skip minification in development, I would first check if I can make the grunt uglify task use a config setting like an environment variable or npm setting, etc. to decide whether to actually uglify or not. If that is not possible, I would make a separate grunt task called "devBuild" that does everything except uglify.

how to distribute a Flash component for use with MTASC?

I have a Flash component that's just a library of compiled code with some exposed API calls. Normally we distribute this as a SWC or MXP, and it works just fine. Recently I had a client express interest in using my component, but they do all their development in MTASC only. MTASC doesn't support SWC files, so ss there a good way to send precompiled code that would work in MTASC? I'm not able to send them the original source code, but if there's some other method I'd appreciate it. I do have access to the source, so I can recompile it however necessary. Thanks!
I did find an answer, and I'm not 100% sure if this is exactly the process since I'm no longer at that job and don't have the computer/process in front of me anymore. It was a bit of a hack.
What it involved basically was unzipping the SWC file and getting a .swf and a bunch of .asi files out.
The .asi files are really just ActionScript files, but they contain intrinsic definitions, or just prototypes or footprints of whats actually there. The real meat of it is still in the .swf.
So you rename all those .asi files to .as and then put them into your MTASC classpath. Since they contain definitions, you shouldn't be getting any more "undefined variable" or "undefined function" errors at compile time. Now you just need to pull in the SWF, where the actual function bodies are defined, using loadMovie. once the loadMovie is complete, you should be able to use all of the functions.
The only caveat of course is that you have to wait for that SWF to load before calling of any of the functions from the SWC.
so step-by-step, it looks like this:
1.) unzip the SWC file. this can be done using WinZip or OS X terminal unzip command
2.) Rename .asi files to .as
3.) add new .as files to MTASC classpath
4.) add AS code to load the .swf in and make sure none of the SWC functions are called before the SWF is loaded
5.) compile
I'm pretty sure this is what we did, but i'm not in a spot to try it out right now.,
Hope this helps, let me know if you have any other questions and I'll see if I can help figure it out any more.

Resources