Skip to content
New issue

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

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

question about what compressor does for me... #82

Closed
gregveres opened this issue Nov 19, 2016 · 7 comments
Closed

question about what compressor does for me... #82

gregveres opened this issue Nov 19, 2016 · 7 comments

Comments

@gregveres
Copy link

Hi

I might have the wrong impression of what autoCompressor does for me.

I assume like everybody else here, I am using MVC to serve up different pages. Each of these pages is pretty much its own SPA with a fair bit of typescript /javascript code spread across many files.

From my initial reading of this project, I was assuming that autoCompressor would analyse each page's javascript and build a bundle per MVC page. The end result would be that each MVC page did one round trip to the server to pull all the needed javascript in a single minimized file. And that this minimized file would contain just the javascript for that MVC page.

Is that the case? If so, I don't understand the autoBundler configuration to achieve that.

I have my typescript files organized this way:

Scripts/
-> Api // files that provide me access to my MVC Web Api back end (models and functions that do ajax calls)
-> App // MVVM view model classes broken out per page, but there could still be some sharing here
-> Controllers // the initial kick off typescript file per Controller Action - this is new since adopting this project
-> Libs // 3rd party libraries I am using.

I guess I am expecting to get to a point where I could have a common include for the app (say jquery, bootstrap and knockout or angular), and then for the controller Actions: Home/Action1 and Home/Action2, I would have two bundles automatically created based on the smallest subset of my typescript code, one called Home/Action1Bundle.js and the other called Home/Action2Bundle.js.

Am I thinking about this correctly?

Thanks a lot
Greg
@aquamoth
Copy link
Collaborator

Yeah, thats how Ive been working towards as well for the last week. Unfortunately Ive been pretty sick too, but my important takeaway is that:

  1. YuiCompressor doesn't handle exports.default, so you must name all exports in your scripts.
  2. Things crash if you compress jquery, so you need to exclude that from your bundles and reference the precompressed file.
  3. autocompress path system is really broken. Ive spent some time rewriting it with proper tests but it is still not stable...
    /Mattias
    Den 19 nov. 2016 08:14 skrev gregveres notifications@github.com:Hi
    I might have the wrong impression of what autoCompressor does for me.
    I assume like everybody else here, I am using MVC to serve up different pages. Each of these pages is pretty much its own SPA with a fair bit of typescript /javascript code spread across many files.
    From my initial reading of this project, I was assuming that autoCompressor would analyse each page's javascript and build a bundle per MVC page. The end result would be that each MVC page did one round trip to the server to pull all the needed javascript in a single minimized file. And that this minimized file would contain just the javascript for that MVC page.
    Is that the case? If so, I don't understand the autoBundler configuration to achieve that.
    I have my typescript files organized this way:
    Scripts/
    -> Api // files that provide me access to my MVC Web Api back end (models and functions that do ajax calls)
    -> App // MVVM view model classes broken out per page, but there could still be some sharing here
    -> Controllers // the initial kick off typescript file per Controller Action - this is new since adopting this project
    -> Libs // 3rd party libraries I am using.
    I guess I am expecting to get to a point where I could have a common include for the app (say jquery, bootstrap and knockout or angular), and then for the controller Actions: Home/Action1 and Home/Action2, I would have two bundles automatically created based on the smallest subset of my typescript code, one called Home/Action1Bundle.js and the other called Home/Action2Bundle.js.
    Am I thinking about this correctly?
    Thanks a lot
    Greg

—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or mute the thread.

@gregveres
Copy link
Author

On Nov 19, 2016, at 2:16 AM, Mattias Åslund notifications@github.com wrote:

Yeah, thats how Ive been working towards as well for the last week. Unfortunately Ive been pretty sick too, but my important takeaway is that:

Great. I am not alone. :) Thanks for confirming. Right now I am in the process of migrating to requireJS. Once that is done, I will turn my attention to the bundling.

  1. YuiCompressor doesn't handle exports.default, so you must name all exports in your scripts.

Ok. That shouldn’t be a problem. I am only using the import X = require(‘x’) format for 3rd party libraries.

  1. Things crash if you compress jquery, so you need to exclude that from your bundles and reference the precompressed file.

Ah that’s good to know. I think I managed to get the compressor to run once and I had jQuery in a bundle but I was getting an error. I thought it very strange that it would error out on jQuery.
I will leave out jQuery then.
Right now I am using MVC’s bundling for jQuery, bootstrap and knockout because I need them on every page.

  1. autocompress path system is really broken. Ive spent some time rewriting it with proper tests but it is still not stable...
    /Mattias

@gregveres
Copy link
Author

Hi @aquamoth

I think we may be pushing in the wrong direction. Now that I have a clearer understanding of the tool and I understand the terms better, I have re-read the bundling page. The example they show is assuming that there is a single bundle per "Area", not per "Action", which is a huge difference.

I need to keep reading, but for right now it doesn't even look possible to automate creating a bundle per page (action). I think I would have to add a new config file entry for every page I create. This is the kind of maintenance I was hoping to avoid.

I guess I could go back and start breaking down my app into fairly small "Areas".

@gregveres
Copy link
Author

Hi @aquamoth

Were you running into errors like this:

RequireJsNet.Compressor.2.2.5\build\RequireJsNet.Compressor.targets(33,5): error : Could not load script C:\Users\gregv\Source\Repos\SquashSpider\SquashSpider\SquashSpider\Scripts\App\FrontDeskFrontDesk.js

Notice the last part of the path is FrontDeskFrontDesk.js. There should be a slash between FrontDesk and FrontDesk.js.

I believe it is picking this up from a require statement that the Typescript compiler created:

define(["require", "exports", 'App/FrontDesk/FrontDesk'], function (require, exports, FrontDesk_1) {

@aquamoth
Copy link
Collaborator

aquamoth commented Nov 25, 2016 via email

@aquamoth
Copy link
Collaborator

aquamoth commented Nov 25, 2016 via email

@gregveres
Copy link
Author

@aquamoth thank you for carrying on the conversation with me. I am trying to learn from others so you sharing how you are doing things is very helpful to me. I appreciate it.

I wouldn't mind hearing from @rangp. He has created a fork of this project to fix the compressor as well. I have to assume that he fixed the bugs in the path system, but he says he is using the MVC bundling system to ensure cache busting.

Ok I see what you are saying. I think my reason for bundling is to minimize the JS code (through uglify) and then to minimize the number of round trips to the server.

I could see that by bundling too high up in the hierarchy you end up delivering too much code to the browser if the user isn't fully exploring that area of the product. And to avoid that you might create very fine grained Areas within your source tree.

So your classification of bundles comes down to:

  • Global (things that every page needs: jQuery, knockout, bootstrap, in my case)

  • Area scripts (what controls the contents of this bundle? are you hand tuning this?)

  • page scripts (the left overs after your area bundling is done?)

I was thinking about the problem a little differently. I believe the shared scripts on a page are due to shared components being used on multiple pages. If I am correct, then I would like to have the ability to create a bundle from the support scripts for a component. I am using Typescript and single responsibility principle so one component sometimes ends up spanning multiple files. I would like to create a bundle for each component. Then there is always going to be the page's view model script that is specific to that page.

So I was looking for a solution that does the following:

  • global bundle

  • component bundles

  • page bundle

I don't want to load any unbundled scripts. It is the minimization of the script that is just as important to me as the joining of the minimized script with other scripts.

Right now I am using MVC's bundling to bundle my global scripts outside of requireJS and RequireJSNet. I would prefer to pull them into the same structure but that's only because I don't like exceptions. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@aquamoth @gregveres