How do you import this library via CommnJS?

[Nick McCready]

Trying to use this via browserify. But I keep getting;

Error: Cannot find module '../tmp/lodash' from '/longPath/node_modules/angular-extend-promises'

[Quentin Raynaud]

This is strange, this module has an UMD definition. Did you tried https://github.com/mattlewis92/angular-bluebird-promises before ? We are not using angular anymore with the other maintainer so this module was not really updated since a long time ago (though it worked well last time I checked).

It is built using webpack so maybe just rebuilding it with an updated webpack version would fix this? You can try from the sources. It contains scripts to do all the work so this should not be hard. If it works I would accept a PR and do a release to help you.

(and yes I know, our implementation is not the same thing since we do not use bluebird but only extend ng native promises, you might prefer this way of doing things...)

[Nick McCready]

Yes I did try angular-bluebird-promises but it had undesired behaviors in digest. I gave up and started my own. But I found this and thought I'd give it ago.

However, this looks outdated. I removed all require('../tmp/lodash") with require("lodash") and it works fine. Seems like something should be changed in your grunt script for the final dist. Or at least make lodash injectable somehow.

Anyway, the api looks too out of date as I am used to Promise.each, Promise.map.. join ..etc without having to call resolve prior.

[Quentin Raynaud]

Those should work too. As stated on documentation, those methods are provided both on instances and on $q. You can do $q.map(...) exactly like with Promise.map. It is old but it did support all modern behaviors at the time (now it's normal). The constructor mode of Promises is also supported even though it's not documented.

You can try new $q((resolve, reject) => ...).

Also I believe we have the only promise implementation on angular that supports "streaming" promises.

Meaning promise.map(process1).map(process2) allows items to flow between maps without syncing the array just like promise.map(item => process1(item).then(process2)).

[Nick McCready]

Ok, weird for some reason $q.each is showing up undefined for me in my specs.

[Quentin Raynaud]

This is weird yes. It was working fine when I used the module. I was also a heavy user of those kind of features.

[Quentin Raynaud]

As you can see here I export each on the $q module.

[Nick McCready]

I think I found one my main issues. My spec was testing a commonModule and I was only loading this module into the main app module.

[Nick McCready]

require('angular/angular')
require('angular-simple-logger')
require('angular-ui-router')
require('angular-extend-promises/angular-extend-promises-without-lodash.js')

mod = window.angular.module 'rmapsCommon', [
  'nemLogging'
  'ui.router'
  'angular-extend-promises'
]

module.exports = mod

Be nice to do this for lodash

require('angular-extend-promises/angular-extend-promises-without-lodash.js')(require('lodash))

[Quentin Raynaud]

Cool. Can I close this or does this require some attention from our side? I'll be very happy to merge a patch to release a version that works well in a CommonJS env though.

[Nick McCready]

I wouldn't close it as I had to manually hack the code to get around the '../tmp/lodash' problem. I could not figure out how to inject lodash into your module.

[Nick McCready]

Just to be clear I am using npm with browserify.

[Quentin Raynaud]

Yes, thinking about it, this module was not designed to be loaded in CommonJS. It expects lodash to be available in the global env. That's not a very good way of achieving this. If you hack the build system to fix this I'll be delighted to merge.

[Nick McCready]

Well one quick approach of a hack is to use us grunt-replace to replace all regexes /..\/tmp\/lodash/ with lodash.

[Quentin Raynaud]

Though the require('angular-extend-promises/angular-extend-promises-without-lodash.js')(require('lodash)) is not a good way of doing this because it would prevent the current global method from working properly. I'm sure it's possible to explain to webpack that it needs to look for lodash in dependencies properly.

[Quentin Raynaud]

If your method does not break other loading methods I'm okay with it. But I'm a little scared about this.

[Nick McCready]

Well yeah if I did the grunt-replace then there would be an entireley different dist file for commonjs / browserify.

But if you were to actually rewrite the injector then it would be something like this.

function bootstrap(maybeLodash){
  return maybeLodash || window._ || require('../tmp/lodash');
}

[Quentin Raynaud]

Should be fixed in 9b91197 (released as 1.0.0).

[Quentin Raynaud]

Oh, by the way, I updated lodash & dependencies while I was at it and I discovered that if you were using a recent version of lodash, it could explain why some methods where missing. The .each and .map lost their last parameter in recent lodash versions and I was using it.

[Nick McCready]

Ahh cool, I will check this out tomorrow. As far as lodash is concerned we're still stuck on 3.X latest.

[Nick McCready]

I don't know if this is resolved as I still can not inject lodash into the module. Since you bumped the lodash requirement to 4.X, I have tried the following:

require('lodash')
require('lodash-migrate')#needed for angular-extend-promises
require('angular-extend-promises/angular-extend-promises-without-lodash.js')

However it still fails TypeError: _.functionsIn is not a function .

[Quentin Raynaud]

Strange. Did you check that your lodash exports _.functionsIn properly because it seems correct? (it should not even be necessary to require lodash previously.

[Nick McCready]

I am only requiring lodash previously to force / override it with lodash-migrate. To patch in ,functionsIn and .zipObject.

[Quentin Raynaud]

Since you get this error and no other, seems like your patch in failed. Just add some debug to check it is there. _ was loaded since it says functionsIn is not a function and not that _ is undefined.

[Nick McCready]

So one thing that occurred to me; why are we bundling a dist file for npm? The raw source should be avialable. With the idea that other peoople's bundlers (webpack, browserify or es6) will take care of the importing . So for the .npmignore I would remove /src . Once this happens then I think my problem might go away.

[Quentin Raynaud]

Your problem would be the same since now everything is importing fine. Your problem is that functionsIn does not seem to be in your lodash.

[Nick McCready]

Note: https://github.com/lodash/lodash-migrate/issues/67

[Quentin Raynaud]

I had this feeling. You can try _.functionsIn = _.methods. Should do the trick here for you. But better yet would be to upgrade to 4.X.