Ping

[buch...@gmail.com]

Hello!

I've been searching around for a DI solution I'm happy with, and I came across your project, to which my gut reaction was "awesome!"

But, I see there's been no activity for a couple years. I'm sure the code works as is, but I'm curious, should I be concerned with
the lack of activity? A project without activity, possibly without a maintainer, always raises a red flag for me.

In any case, I think you've produced an excellent chunk of code here! So thanks!

[Roy Jacobs]

Thanks for the feedback! The reason there hasn't been a lot of activity is that I think that the Javascript module system has gained enough traction to be used browser-side as well, through libraries like Browserify or as a precompilation step with Require.

These module systems essentially give you a named singleton or factory method, so there's really no need for a more complex mechanism. In fact, the only major library that's currently using a "traditional" DI approach is Angular and even there I don't think it would've been necessary.

Still, Intravenous is a nice bit of code and I'm happy to see that people are still looking at it :)

[Alex Buchanan]

Agreed. Since my message, my train of thought has tended towards Browserify, which I'm pretty set on now. Still, having a clean way to mock modules on a per-test basis is important, which I'm exploring now.

--
You received this message because you are subscribed to a topic in the Google Groups "Intravenous" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/intravenousjs/LhbRCLlgbPw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to intravenousj...@googlegroups.com.
To post to this group, send email to intrav...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/intravenousjs/3d2c9b49-2646-451e-b3a0-9ca1df986d8d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Roy Jacobs]

Agreed. Since my message, my train of thought has tended towards Browserify, which I'm pretty set on now. Still, having a clean way to mock modules on a per-test basis is important, which I'm exploring now.

Facebook just released an interesting library that "mocks by default": http://facebook.github.io/jest/

Not sure if I like their mocking syntax, it seems awfully verbose, but it could be an interesting starting point for you.

[Alex Buchanan]

Interesting, thanks for sharing. I hadn't found Jest yet. It's been surprisingly tricky to track down all the various javascript unit testing/mocking/DI solutions out there.

I'm not sure I like being tied to the whole jest stack (jasmine, test runner, etc), but maybe the custom require() could be extracted.

I wrote a modified version of require() based on browserify's which included a mocking mechanism. Then I woke up this morning and realized that it required the module being mocked to be loaded before it could set the mock, and maybe that's a bad thing (what if module loading has side effects?). Seems like Jest has the same trait, but likely provides ways to work around those cases, and maybe those cases are the minority anyway.

--

You received this message because you are subscribed to a topic in the Google Groups "Intravenous" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/intravenousjs/LhbRCLlgbPw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to intravenousj...@googlegroups.com.
To post to this group, send email to intrav...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/intravenousjs/8f6dad98-8376-4b1c-acb1-8c712c4805f2%40googlegroups.com.

[buch...@gmail.com]

Finally found something that matches what I was dreaming of almost exactly, thought I'd share with you.

http://teropa.info/blog/2014/03/18/using-angular-2-0-dependency-injection-in-a-backbone-app.html
https://github.com/angular/di.js

On Wednesday, May 21, 2014 10:02:15 AM UTC-7, Alex Buchanan wrote:

Interesting, thanks for sharing. I hadn't found Jest yet. It's been surprisingly tricky to track down all the various javascript unit testing/mocking/DI solutions out there.

I'm not sure I like being tied to the whole jest stack (jasmine, test runner, etc), but maybe the custom require() could be extracted.

I wrote a modified version of require() based on browserify's which included a mocking mechanism. Then I woke up this morning and realized that it required the module being mocked to be loaded before it could set the mock, and maybe that's a bad thing (what if module loading has side effects?). Seems like Jest has the same trait, but likely provides ways to work around those cases, and maybe those cases are the minority anyway.

On Wed, May 21, 2014 at 1:09 AM, Roy Jacobs via Intravenous <intravenousjs+noreply-APn2wQevt4KNqcQ080_JAt4z7CUH98fOLUTxG8IO9a@googlegroups.com> wrote:

Agreed. Since my message, my train of thought has tended towards Browserify, which I'm pretty set on now. Still, having a clean way to mock modules on a per-test basis is important, which I'm exploring now.

Facebook just released an interesting library that "mocks by default": http://facebook.github.io/jest/

Not sure if I like their mocking syntax, it seems awfully verbose, but it could be an interesting starting point for you.

--
You received this message because you are subscribed to a topic in the Google Groups "Intravenous" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/intravenousjs/LhbRCLlgbPw/unsubscribe.

To unsubscribe from this group and all its topics, send an email to intravenousjs+unsubscribe@googlegroups.com.

To post to this group, send email to intrav...@googlegroups.com.

[Roy Jacobs]

Excellent, good to see you found something that works for you!

[Morgaine Fowle]

The big capability I really miss that was distinct and fresh about intravenous was the ability to nest containers. I really liked the ability to fork a copy of a container.

Thanks for the cool project Roy.