Publish to npm for browserify support

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

👍

@mattrobenolt

👍

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?

@christophercliff

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

👍 for browserify support

@clayzermk1

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.

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.

Prepare package to be uploaded to npm

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.

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.

@moretti

@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.

@mattrobenolt

@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).

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

This would be lovely.

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>

@mattrobenolt

@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.

@dcramer

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.

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.

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();

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

@mattrobenolt

Thanks @mattrobenolt

@mattrobenolt

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

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

Works great, thank you.

Prepare package to be uploaded to npm

rm -rf udp (#197)

meta: Add changelog entry for 0.5.1 (#197)

Navigation Menu

Repository navigation

Publish to `npm` for `browserify` support #197

1 remaining item

Workarounds for using with webpack

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Publish to npm for browserify support #197

Description

Activity

bobbyrenwick commented on May 15, 2014

christophercliff commented on Sep 10, 2014

mattrobenolt commented on Sep 10, 2014

clayzermk1 commented on Sep 13, 2014

moretti commented on Nov 3, 2014

mattrobenolt commented on Nov 3, 2014

mattrobenolt commented on Nov 3, 2014

moretti commented on Nov 3, 2014

mattrobenolt commented on Nov 3, 2014

clayzermk1 commented on Nov 3, 2014

moretti commented on Nov 3, 2014

tommoor commented on Jan 16, 2015

twolfson commented on Jan 16, 2015

piuccio commented on Feb 13, 2015

1 remaining item

mattrobenolt commented on Mar 2, 2015

grrowl commented on Mar 2, 2015

dcramer commented on Mar 2, 2015

fson commented on Mar 2, 2015

Workarounds for using with webpack

mattrobenolt commented on Mar 8, 2015

piuccio commented on Mar 8, 2015

clayzermk1 commented on Mar 9, 2015

mattrobenolt commented on Mar 9, 2015

chromakode commented on Mar 9, 2015

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

Publish to `npm` for `browserify` support #197