These are chat archives for brunch/brunch

27th
Jan 2017
Colin Bate
@colinbate
Jan 27 2017 02:34

So, I've come up against a couple of issues now which I suspect are related to the way deppack module discovery works. It might be legitimate limitations, or unsupported features or bugs, I'm not sure.

First issue was trying to resolve @angular/core/testing (or any other similar testing module in the Angular code base). The problem was that particular folder's index.js file uses ES modules. There is a package.json in the folder which only contains a main property pointing to the core-testing.umd.js file in another folder. It doesn't seem that "redirect" is being picked up. That may or may not be due to the fact that the package.json file in question is technically invalid (no name or version).

We worked around this particular issue by using npm.aliases in the brunch-config.js file:

npm: {
  aliases: {
    '@angular/core/testing': '@angular/core/bundles/core-testing.umd.js'
  }
}
Aleksey Shvayka
@shvaikalesh
Jan 27 2017 02:37
@colinbate it sucks, but we can't fix that immediately. we have no resources to support another bundler, so plans are to use existing one. please, copy & paste your message in issue, so I can easily track all deppack issues
Colin Bate
@colinbate
Jan 27 2017 02:41

The second issue I ran into today while doing some code tidying. I noticed that we were importing the whole rxjs library in one file, but were supposed to be only importing the parts we needed like rxjs/Observable or rxjs/add/operator/map. After I removed the reference to the whole package, I started getting run time errors saying that some third party npm module (Angular) couldn't resolve rxjs/add/operator/whatever. If I manually imported that particular operator, it would fail with another package requiring a different operator. I played it safe for now and just re-referenced the whole base package of rxjs.

The issue here is that these Angular (and others) packages are actually UMD bundles and I suspect deppack isn't finding their dependencies correctly.

@shvaikalesh I'll put these into issues then. Thanks for the feedback.
Neya
@dsignr
Jan 27 2017 03:19
Could someone confirm if you're facing this issue: brunch/brunch#1610
Strange that for me it works on one machine while on the other the bug still exists..
Colin Bate
@colinbate
Jan 27 2017 03:33
Are the two different machines the same OS? There have been cases in the past where Windows behaves a bit differently.
Neya
@dsignr
Jan 27 2017 03:35
One is a Macbook pro, other is a Mac Mini. Both running the latest versions of the OS. Stuff I tried:
1) Delete node_modules folder and re-run npm install
2) Run npm cache clear
Still the ordering is wrong. I currently have access to the machine where the order fails, if you'd like me to try something, would be happy to oblige :)
Colin Bate
@colinbate
Jan 27 2017 04:01
I tried cloning your test repo and I can't seem to do anything to get jQuery to be written out before your hello world statement.
Neya
@dsignr
Jan 27 2017 04:04
So, this issue is still valid, right? I think I should re-open it again..
Thank you very much for your time @colinbate
Colin Bate
@colinbate
Jan 27 2017 04:06
Vendor files are supposed to go first by default. And they are being recognized as vendor files since they aren't being wrapped even when I enable module wrapping.
It is quite frustrating. :smile:
Neya
@dsignr
Jan 27 2017 04:07
I see. Yes, what I don’t understand is how does this work on another machine? :O lol
Colin Bate
@colinbate
Jan 27 2017 04:08
I've not used a vendor folder before, but my experience with before and after has never given me trouble before
I tried with Windows 7 just now. I can try on my MacBook in a bit
Neya
@dsignr
Jan 27 2017 04:09
Wow, thanks so much for your time Colin, much appreciated! :)
a69d84379a04cc6f56a58c1c9b8d0826ddd24c9e52644ac7a068705a7be1a6bb.jpg
Colin Bate
@colinbate
Jan 27 2017 04:15
You may want to just bundle the vendor files into a separate JS file and then reference that first in your HTML. That way your app.js is the only file which changes as you write code.
Neya
@dsignr
Jan 27 2017 04:16
Yeah, that’s the fallback I’m using now, but I deally I wouldn’t want to use two separate http requests.
Colin Bate
@colinbate
Jan 27 2017 04:16
Something like:
joinTo: {
          'js/app.js': [/app\/js/, '!app/js/vendor/**/*.js'],
          'js/vendor.js': /app\/js\/vendor/
        },
Well, you could concatenate them together afterwards (which defeats the purpose of using Brunch I suppose) or serve over HTTP/2 which doesn't care so much about the number of files.
Neya
@dsignr
Jan 27 2017 04:18
Well, you could concatenate them together afterwards (which defeats the purpose of using Brunch I suppose)
Exactly! :(
Colin Bate
@colinbate
Jan 27 2017 04:19
I will second the opinion of using modules to help organize your code. Obviously not so easy if working with an existing code base, but if you are starting out new, definitely consider it.
Neya
@dsignr
Jan 27 2017 04:19
Ok, thank you. I plan to explore the use of modules in my new project too :)