Add pusher-js to npm package registry #84
Comments
+1 |
Hi, |
It doesn't need to be Node compatible. Publishing it to npm is necessary to use the pusher-js with browserify |
This really needs to be added. +1 |
The npm site has been redesign recently and its new tagline is "npm is the package manager for javascript" ...I thought that it would be worth sharing it here as it shows the current trend of how npm is used by developers and its future direction. So again |
Hey all - this is a discussion that we've also reopened internally. I'd like us to take a look at adding a UMD wrapper to pusher-js so that we can publish to NPM. It may just be a simple build step but we need to do a bit of investigation and testing... We'll update this issue as soon as things are a bit clearer. Thanks for the |
+1 |
I've made a first attempt at supporting CommonJS includes by adding a UMD wrapper. I've done a simple build with Browserify and tested Flash and HTTP fallback. I'd certainly appreciate it if others could test this. You can grab the built version of this here: It's important to point out that:
However, this should let people include an use pusher-js via NPM and build with Browserify which I believe is the main objective. If this UMD header appears to work we may be able to include it in a future pusher-js release and then we can start publishing it on npm as part of our release process. But there's a bit of testing that needs to be done before we do that and a decision about the version that gets the UMD header. Please let me know if you have any feedback or questions about this. |
@leggetter when are you planning to release this change? |
@mwjackson - I'm working towards making sure that I can run all the tests we have against the pusher-js version that's been built with a UMD wrapper. I've got the unit tests running and passing but I need the integration test suite to be passing before I'd be happy to release it. Hopefully this can be done within a week. |
+1 for the umd wrapper. The sooner the better, please |
Update: we have an internal version of this working and tested with Browserify. However, we've taken the opportunity to look into migrating the build process to more common node-based tooling. This includes testing, building and deployment processes. We could release an early version, but there are some unanswered questions related to versioning and loading dependencies from a CDN. I'll try to speak to @pl about this over the next few days. Sorry that it's taking so long to get this out. |
Any news regarding this? |
The plan is for it to be in v3.0 of the library. It will contain:
We'll try to get an alpha (a full version release may be quite a bit longer) of this out within the next three weeks. But it depends on what's prioritised and how much time we get to spend on library development. Fingers crossed an I will update this thread if there's any progress. |
Would be great to have that |
|
Quick update, @pl has been working on moving the deployment tools to node but it's a bit more difficult that we hoped. We're pondering options |
Do you need to convert your build tools to node to release a UMD wrapper? |
@mwjackson @juliankrispel We are using UMD. Specifically we're using https://github.com/umdjs/umd/blob/master/commonjsStrictGlobal.js Right now the library internals have dependencies on a global
There are a number of reasons for the move to a different set of tooling.
Right now we have a branch in a private repo that works.... but we can't test in IE6 or IE7 due to problems with the Node-based Jasime test runner Hopefully that clarifies why this isn't as easy as top and tailing the existing script with a UMD header and footer. And hopefully we'll be able to solve the IE6 and IE7 testing problem (we do have customers who need this). So, if anybody knows of a Gulp-based Jasmine 2.0 Test Runner that works in IE6+ please let us know |
@leggetter thanks for shining a light on this |
Another solution would be to drop IE6 and IE7 support for the new lib. IE6+SSL is already broken because we removed SSLv3 support a while ago to prevent the POODLE attack. |
I guess the question is whether those customers can continue to use the old version for their IE6/7 support. We don't have that requirement (thank god), so obviously the sooner you can get this out the better. |
And we could drop the JSON polyfill. Just as a curiosity, why do you guys want npm packaging, to manage your dependencies with a single tool ? |
We use browserify so would like to just |
We have a similar situation to @jhollingworth, but using webpack. |
Alright. I've got a r3.0.0 branch with UMD and a couple of other things. Anyone wants to test it out ? |
I'll try it. |
Thanks, for browser testing you can also go directly to http://test.pusher.com/?version=3.0.0 and play around with the client |
I got the chance to play a bit with the new 3.0.0 branch today. define([], function () { I manually changed and tested and it works fine in latest ff and latest chrome on windows. Haven't got the chance to do more tests but will surely do in the following days. Fun fact: I did actually have a "pusher" module installed (the node.js client) and all hell broke lose when I tried to compile as it was trying to load that module to satisfy the dependency. Without the "pusher" module it would simply say "pusher module not found". |
See pusher#84 (comment) for more details.
Thanks @terebentina, I'll update src/build/umd_header.js to match what you said. |
I have made another build with the updated headers if you want to give it another try |
Yep, ok, will test tomorrow. |
Ok, this works fine now. For the record, I bundle my files with webpack. Maybe someone who uses browserify could test it too? |
|
Awesome +1
|
This is strictly still a release candidate, but I've used it a bit and it seems "all good" to me. I've also created a super-simple reference here really just to check things build and work as expected: Please leave any feedback here. Sorry this has taken SOOOOO long |
Since there hasn't been any further feedback and pusher-js is in NPM I'm going to close this issue. Thanks to everybody that contributed. We'll officially announce the release pusher-js 3.0.0 shortly. |
We're sadly seeing issues with webpack. @m4tthumphrey could you tell me what you did to get it working? We get the following warning:
Followed by many errors all related to
To reproduce please check out this repo: |
Sound like you are using "pusher". The NPM module for the browser library
|
Whoops… * facepalm * |
I am trying to use the NPM package in a React application. I am importing the package like so:
But when I compile with webpack I get the following error:
Any ideas? |
@joshhornby Use CommonJS syntax to import pusher-js: We've been successfully using pusher-js with webpack. |
@DanielApt Thanks for the advice. Still getting the same error about the window not being defined. Have you used this is a react application? |
@joshhornby No, we haven't used it in combination with a react app. I'm a bit stumped on this one… What is the target of your webpack project? Window being undefined would make me think it's set to |
@DanielApt I'd suggest going back to basics and working out where the problem is introduced. There's a very basic webpack example here: How about starting there and building up to include react etc. Or have you resolved the problem now? |
@leggetter This is actually @joshhornby's issue, not mine. Anyways… @joshhornby I suggest you look at the above comment. |
Thanks @leggetter will take a look. |
was there any resolution to this error im getting the same.. |
Never mind worked out what the problem was to do with isomorphic application when using react. It was requiring the lib while on the server before hydrating to the client. |
@everblaze @joshhornby how did you resolve this? I'm getting the same error with a react app. |
@coderholic can you replicate the bug in a GitHub repo that we can look at? I'd recommend checking out Phil's comment above [https://github.com//issues/84#issuecomment-118828651] and going from there. If you still have the problem also it might be worth opening a new issue; this issue is pretty long and not that easy to track problems in. A new issue will be way easier for all involved :) |
Would be helpful for those who use npm for front-end dependencies. Any plans?
The text was updated successfully, but these errors were encountered: