Meneus: Which, if it’s an npm module, it shouldn’t

Meneus: Though I don’t know what kinda environment stuff it sets up

Hogenmiller: BigJono: for things like that, you usually want to load the module only in your entry point module, then p*** that down to all modules that need it. You need to do this for React too.

Knuckles: BigJono: https://github.com/robotlolita/jumperskirt/blob/master/src/index.sjs#L27-L37

Meneus: Why would highcharts pollute your environment though?

Loup: But in your index.js you’d have var HighCharts = require’highcharts’; then var a = require’./submodule’HighCharts; var b = require’./submodule2’HighCharts; .

Kumro: Meneus: dunno. Never used it

Lehane: I thought the whole point of browserify was that it’s loaded once then the reference is given wherever require is used?

Meneus: That’s a good point – I’m pretty sure browserify does what it does by wrapping everything in a closure and p***ing in the deps as arguments that can then be pulled by require

Grabski: BigJono: no. The whole point of browserify is allowing you to define your dependencies using require. It doesn’t guarantee you that the dependencies are going to be loaded only once because you can get cache misses, or you can clear the cache between different requires, or .

Meneus: BigJono: does highcharts have any initialization code you need to call? or is it literally trhe act of requiring it that causes this?

Franck: I think it’s the act of requiring it. I’m using react-highcharts, so it’s a react component. You just require it then create it as a react component and p*** a config object like Highcharts config={}/

Mckey: Btw this started happening when I added proxyquireify to my testing toolkit

Hanrath: BigJono: does react-highcharts require its own version of React?

Tugwell: I feel like that was probably important information I should have added at the start.

Murton: Nope, just normal react

Scala: BigJono: anyway, what is the error you’re getting?

Ash: And what’s proxyquireify?

Jefford: Http://www.highcharts.com/errors/16

Healey: Proxyquireify lets you mock dependencies when testing commonJS modules

Jividen: Ughhhh, this proxyquireify thing is garbage. Is there a better solution for isolating a module in a front end codebase to unit test using Jasmine?

Gutowski: Https://nodejs.org/en/blog/release/v4.0.0/ its happening

Ferrence: Well yeah, but how do you do dependency injection?

Tlamka: Nvm got it to work, I’m an absolute idiot

Ngyun: I asked just before whether CommonJS modules should have side effects. Turns out one of my modules had a side effect, and it was breaking everything.

Mcginty: Hopefully next time I get advice I keep to it for more than 3 hours 😛

Angelino: BigJono: parametric modules are the best way of isolating dependencies.

Solorio: Is that where you p*** dependencies in as parameters when initiating a module?

Curcio: Module.exports = functiondepA, depB, depC{ return { theModule: using, depA: depB, and: depC } }

Hemmig: Ohhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh and suddenly it all makes sense

Certain: Is there any good collections of javascript best practices that would have told me about that before I started developing? Would probably have saved me a lot of heartache

Degener: BigJono: http://jstherightway.org/ might be useful

Sackey: Cheers, I’ll give it a read

Shoeman: So I have a web app that I’m building that my business partner is super paranoid about letting any hint of it out on the web

Sakamoto: With that in mind,, i want to use a bug tracking application, what would you recommend?

Hamre: Heh sorry if i had to give that precursor, it was info just in case

Hallinger: He knows that like, its gonna be . on the web

Caamano: Lol yeah eventually it willl