Issue with using it as an npm module

[iyip]

I tried to use it as a client side dependency pulled in via npm. Since I can not find it in npm registry, I put this in my package.json:
"export-csv": "git://github.com/highslide-software/export-csv.git",
when I do npm install, it give me this error:
npm ERR! addLocal Could not install /var/folders/17/753bdfvj71jc_7w4s1lp2b7c0000gy/T/npm-3336-fb0db841/git-cache-90a11606310f/a91b014fb5f87d6c7ab64171d413e912cb92bde3
npm ERR! Darwin 14.5.0

I can pull in highcharts just fine by
"highcharts": "git://github.com/highslide-software/highcharts-release.git#v4.1.9",

How do I know which name to use? "export-csv" or "export-csv-plugin" or something else?
Also is there a browserify version of this plugin (CommonJS compatible)?

[TorsteinHonsi]

We are currently going over Highcharts and all modules as well as our own plugins and preparing them for NPM. @jon-a-nygaard

[lmaccherone]

Any update on this? I would love it if you made it available directly in npm like highcharts does now.

[TorsteinHonsi]

We'll go over the plugins and prepare them for CommonJS and npm after new year.

For this particular plugin however, we will probably make it a Highcharts module, which means it will be part of the API and follow the core Highcharts release cycles, testing procedures etc.

[felixfbecker]

@TorsteinHonsi I'm currently preparing a PR for highcharts-export-clientside, see this issue. I'm adding UMD loader support and package.json so it can be published to NPM and used with Browserify. The module depends on export-csv, so of course I would like to express that as a package.json dependency that does not use globals.

For this particular plugin however, we will probably make it a Highcharts module, which means it will be part of the API and follow the core Highcharts release cycles, testing procedures etc

What does this mean? Should I instead drop the dependency on this module because it's part of the core API? Are there any changes needed in the code for this?

If the inclusion in the core API is going to take more time would you accept a PR to add CommonJS support?

[TorsteinHonsi]

If the inclusion in the core API is going to take more time would you accept a PR to add CommonJS support?

Yes we may accept that.