Publish to npm for browserify support

[twolfson]

In order to support browserify, a JS compiler that resolves dependencies as if they were npm dependencies, we should publish raven-js to npm.

https://github.com/substack/node-browserify

The changes that we need to make this happen:

• Rename package.json to raven-browser or similar
• Remove private property from package.json
• Get approval from maintainers

If you are concerned about the task of adding 2 more tasks when you release (i.e. bumping package.json version and running npm publish), then you might want to consider using foundry:

https://github.com/twolfson/foundry

[bobbyrenwick]

👍

[christophercliff]

👍

FYI, there is a fork published to npm, but it's rather out of date: https://www.npmjs.org/package/raven-js

@mattrobenolt Any interest in losing the fork and making the main repo CommonJS compatible and publishing releases to npm?

[mattrobenolt]

@christophercliff I'm ok with doing that, I just need someone to hand hold this and support it since I don't use browserify.

[clayzermk1]

👍 for browserify support

[moretti]

Any update? Essentially you just have to merge the PR that @clayzermk1 submitted (#261), remove "private": true from package.json and update the npm package.

[mattrobenolt]

Just merged #261. I think there are a few other issues/PR's to address, then I'll cut a release and try to get this onto npm.

Anyone here willing to test when I publish? Or want to give me instructions to test on my own? I don't want to break the public package that others depend on.

[mattrobenolt]

This is going to be awkward now having a package called raven and one called raven-js both in npm. 😞

I need to figure out a way to combine these two or something into something that can be used in both places.

[moretti]

Yeah I agree, it's confusing, it would be nice to figure out a way to combine them! 😃
I can test the package once it's published, I think it should work fine, though.

[mattrobenolt]

@moretti Thanks. I'm going through my backlog of issues and pull requests today so I'll try and cut a new version this afternoon unless there's a major reason I can't.

[clayzermk1]

@mattrobenolt

I need to figure out a way to combine these two or something into something that can be used in both places.

CommonJS 😉. I think it all boils down to whether raven's dependencies would work browser-side (I don't think they do currently).

Anyone here willing to test when I publish? Or want to give me instructions to test on my own? I don't want to break the public package that others depend on.

I would be more than happy to give it a go! 😄 Testing is easy, npm install raven-js should pull it down, check the package.json that the version matches the code base (make sure you tag the release in git before doing an npm publish).

[moretti]

The simplest way for combining these projects would be to define two different entry points: one for node.js and another one for browsers. This can be done by editing the "main" and the "browser" field in package.json:
https://github.com/substack/node-browserify#browser-field

Have a look, for example, at superagent's package.json:
https://github.com/visionmedia/superagent/blob/master/package.json

[tommoor]

This would be lovely.

[twolfson]

For what it's worth, since the opening of this issue I now prefer to always separate raven from the rest of my JS. If there is anything that would cause the compiled JS to fail and block raven from getting set up, then that is bad. As a result, I usually put it in its own script tag and initialize it before the other JS.

<script src="raven-with-init.js"></script>
<script src="index.min.js"></script>

[piuccio]

@mattrobenolt any update on this?

All you need to do is
git checkout 1.1.16 npm publish ./

This will publish 1.1.16 on npm, the code will be exactly the same as the github tag.

You are already a maintainer of raven-js it should work even if the repository is different.

Would be nice if you could publish 1.1.16 and then work on next versions or merging with raven-node. It would be very useful for many of us.

[grrowl]

+1 would be great if npm could be updated. We just pushed some code using .setUserContext(), a function which isn't documented against a version, but is unavailable while relying on the npm published version.

[mattrobenolt]

So allow me to explain the problem and why it's not so simple:

This module was never intended to be published to npm in the first place. The project was forked and published without our permission. This fork even diverged from master. That's the version 1.1.11 that you see there today, which does not match the 1.1.11 release tagged in this repo.

After that confusion, I've acquired ownership of the repository. I'm hesitant to just publish 1.1.16 to npm since I'm not super familiar with this space and how people use npm for client side dependencies.

With that said, @dcramer and I are going to get this sorted out soon and fix this so we can move forward with our version and nor a forked version that we don't support.

So again, I apologize for the confusion, but I'm trying really hard not to make people more upset by breaking compatibility.

[grrowl]

Understandably. Basically it should be CommonJS (the fork has removed noConflict support but this isn't neccessary -- jquery has both noConflict and AMD/CommonJS support), and will require some changes to package.json.

I appreciate not breaking compatibility and measuring twice, cutting once. Good luck, hopefully a contributor can kick in some time if you need it.

[dcramer]

See also #323

[fson]

@dcramer @mattrobenolt I'm currently using Raven.js installed from npm with webpack, so I could chime in with some experiences. I installed Raven.js 1.1.16 directly from GitHub (so I'm not using the fork published in npm, which is outdated).

Issues I had to work around:

• Latest release didn't have the main field in package.json and the name field was raven.This has been fixed in master since then, but a new release is needed.
• webpack understands even AMD modules, so this was not really an issue with it, but you'll want something like UMD wrapper to ensure compatibility with CommonJS, AMD and globals.
• Make sure that Raven.js doesn't set any globals, when CommonJS or AMD is used. UMD wrapper should take care of this. I had to resort to noConflict as a workaround.
• Expecting this at the root scope to be window. This does not work when using a module system. Because Raven.js depends on the actual window global, that could fixed by removing this this wrapper and referencing window directly. The issue is caused by this wrapper:

;(function(window, undefined){
  // ...
})(this);

Workarounds for using with webpack

These issues are quite easily fix. In the meanwhile, it's already possible to use the current version Raven.js with webpack and npm:

• install from GitHub:

npm install getsentry/raven-js#1.1.16 --save

• use imports-loader to define this – put this in module.loaders:

{
  test: require.resolve('raven/dist/raven.js'),
  loader: 'imports-loader?this=>window'
}

• if you are using the latest release version (1.1.16) from GitHub, you'll need to add an alias to compensate for the missing main field and name being raven and not raven-js:

  resolve:
    alias: {
      'raven-js': 'raven/dist/raven.js'
    }
  }

• call noConflict so you don't expose Raven as a global:

require('raven-js').noConflict();

[mattrobenolt]

1.1.17 was published to npm. I have no idea if this really works, so some confirmation would be great. :)

[piuccio]

Thanks @mattrobenolt

[clayzermk1]

@mattrobenolt Thank you for publishing this! I just upgraded to it and have had no problems building or running it yet.

[mattrobenolt]

Awesome, good to know. I'll be keeping the npm version up to date now as well. :)

[chromakode]

Works great, thank you.