mimosa modules optimize.

[krokhale]

I am in the process of porting over an app to use the modules in mimosa, its working for the most part as we had discussed in an earlier ticket, though when running the watch with an optimize option, it blows up, i will try to post a more detailed error log later, but just a heads up, let me know if optimization with modules works as expected for you. Thanks!

[dbashford]

I think I know the problem you are having. I ran into it too. It's an issue with source maps. Let me see if I can figure out a workaround.

I suspect if you do a mimosa clean -f and then a mimosa watch -so that the first time everything builds ok and the site works, but when you change a file everything breaks? I also suspect you'll have a lot of very odd looking files in your watch.compiledDir (public), with names like foo.src.js.src.js or foo.map.js.src.js or somesuch.

[krokhale]

yes! the source maps, i can live with odd source maps :) but i get this in firebug:

NetworkError: 404 Not Found - http://test.lvh.me:3000/javascripts/main-built.js

My layout has:

script(src='/javascripts/vendor/requirejs/require.js', data-main='/javascripts/main.js')

I have a common.js, similar to the example app, the main1 in example app is main here, thats the only change.

Seems like when its optimizing, it does not take into account the modules config and paths in common.

I would have expected, each module (the dependencies within that module are compiled automatically by r.js into the final js file, we don't care about those) mentioned in the module config to have compiled into a minified optimized js file in public with the module name as the name of the file.

Let me know if i am missing anything.

[krokhale]

The modules are still workable though and do provide a performance improvement over the earlier mimosa, just that there is a request made to get each file, which can be avoided by having just one request to a compiled optimized module file, which would be ideal.

[dbashford]

I'm afraid I'm not fully understanding. You are having an issue with the example app as it stands?

And "just that there is a request made to get each file, which can be avoided by having just one request to a compiled optimized module file, which would be ideal" <= I'm afraid this isn't make sense to me. You have the ability to create the optimized files now. So what would be ideal?

[krokhale]

Sorry, let me be more precise:

The structure is same as the example app.

This is a part of what common looks like:

require
  urlArgs: "b=#{(new Date()).getTime()}"
  paths:
    jquery: 'vendor/jquery/jquery'
    appBase: 'app/base'
    models: 'app/models'
    backbone: 'vendor/backbone'
 shim:
   jquery:
     exports: '$'
  underscore:
     exports: '_'
  application:
     deps: ['jquery', 'ui', 'bootstrap']
  backbone:
    deps: ["underscore", "jquery"]
  exports: "Backbone"

This is what main1 looks like:

require ['common'], ->
  require ['appBase','app/routers/app_router', 'jquery', 'underscore','backbone']
  , (App, AppRouter,  $ ,  _ , Backbone) ->

This is what mimosa config looks like:

optimize :
    modules: [
        name: 'main1'
    ]

Now what is happening in terms of requests, is that there are 1 GET request for each of those required files (total of 5), which should have been just one js file called "main1.js", which had all those 5 files in it, IF it was optimized. (the name would be main1.js since we defined it in mimosa config and r.js automatically adds those 5 dependencies during optimization unless we use 'exclude' and exclude certain files)

IF its not optimized, 5 GET requests are totally normal, and that works great for now. Hope that makes it clear.

[dbashford]

So to paraphrase, for the above scenario, when you optimize, you are not seeing the requests reduce down to 1? The requests stay at 5.

[krokhale]

Yes, the requests stay at 5 for the optimized version too.

[dbashford]

Using the MimosaDynamicRequire I see all the requests I expect and none of the requests I do not expect.

Could you fork that repo to create the situation that is the problem?

[dbashford]

As far as running watch in optimize mode and expecting r.js to do all the right stuff...I'm not going to be able to support that in the near term. Afraid there are far too many moving parts. It all has to do with the modules config. If you were just building a single file that works fine. But when using the module config, r.js does all sorts of extra stuff with the files that Mimosa can't clean up or fix.

I am going to release an update that allows mimosa clean to work better with the modules scenario. This way you will be able to mimosa watch -so and see how things work, then CNTL-C, then mimosa clean which will clean up all that r.js has done, then mimosa watch -so again. It always works the first time assuming its working with a clean folder.

You probably should be doing your dev with optimization turned off anyway. Being able to run watch -so allows you to test the optimized files, you'll just a have a few hoops to jump through to iterate over the result if for some reason the optimized version has some kind of issue.

[dbashford]

I had a couple ideas on this come to me overnight. May give fixing the source map, running mimosa watch -o with modules thing a shot here in the next few days. Might be able to solve that problem.

I do need a concrete example of something not optimizing properly though. A github repo would be perfect.

[dbashford]

I've made some progress, but it appears as if, for now, having source maps work with each subsequent compile will be an enormous undertaking. I can get source maps to work for the first run, but every subsequent run will fail because of the added source maps from the previous run.

So my choices are:

1. Disable source maps for modules runs
2. Stop mimosa watch from re-executing r.js after the first run, because r.js will screw up

I think source maps are fairly important here, but I think disabling and letting you re-enable for 1 run attempts with them might be the way to go.

[dbashford]

https://github.com/dbashford/mimosa/blob/master/RELEASENOTES.md#major-changes

I've address the ability to re-run optimization for modules, details in the release notes. This isn't released yet. I hope to get it out in the next 36 hours. It requires some doc updates.

Still need some confirmation and an example app for modules not reducing requests.

[dbashford]

FYI, if you are doing modules work, may want to check https://github.com/twill88/mimosa-requirebuild-module-include

[krokhale]

Hey, sorry about the delayed reply, been super crazy at my end, thanks, i have just shared an app that i am trying to port over to mimosa with you, you could start it up the usual way, and goto:

http://test-college.lvh.me:3000/sign-up

and after signing in, this page might be a good example of why wrapping the js files into one would be a good idea:

http://test-college.lvh.me:3000/app#account-settings

If you will notice in the forms_layout.coffee, we have these bunch of js files, and in the firebug we have each one of them being fetched individually.

And if i try to optimize, i get this(notice that mimosa config does not have a list of modules, i have not committed that in yet):

NetworkError: 404 Not Found - http://test.lvh.me:3000/javascripts/main-built.js

Thanks for the tip on that requirebuild, i will definitely look into it this week and let you know!

[dbashford]

If you are optimizing via modules, then there is no longer a main-built.js. See here:

https://github.com/krokhale/skynet-node/blob/master/views/layout.jade#L34

I assume that is your base layout. You are including both the main-built and main, but you should just be including main.

This...

//    if optimize
      script(src='/javascripts/main-built.js')
//    else
      script(src='/javascripts/vendor/requirejs/require.js', data-main='/javascripts/main.js')

should be this...

      script(src='/javascripts/vendor/requirejs/require.js', data-main='/javascripts/main.js')

When you use modules, you still need require.js because you still need to async load things in. See the DynamicModule code here: https://github.com/dbashford/MimosaDynamicRequire/blob/master/views/layout.jade#L11

[dbashford]

Any chance to take a look? Any trouble?

[dbashford]

Closing this. Feel free to open something new with details/specific.s