search

mulesoft-labs / js-client-oauth2

A JavaScript implementation of an oauth2 client, for inclusion in the JavaScript client generator for APIs described with RAML.
Other
539 stars 146 forks source link

Any plans to release a standalone browser version? #39

Closed kirill-konshin closed 7 years ago

kirill-konshin commented 7 years ago

Currently this package is distributed only through NPM. Are there any plans to release a standalone browser version, that does not require NPM/Webpack/Browserify?

Such browser-oriented version can be distributed through Bower.

It also implies that some sort of build procedure will be needed, or we can re-organize the code so that one file will fit all.

blakeembrey commented 7 years ago

It used to be like this, it's not much fun to maintain. If there's a build infrastructure set up that doesn't mess with Git I'm happy to adopt it. E.g. if it automatically pushes built into GitHub release files, that would be ideal. I don't really have any desire to support Bower directly, I've never had success with any of my open source projects being on Bower.

kirill-konshin commented 7 years ago

I agree that it's no fun, but lots and lots of people still use JS in a straightforward way w/o fancy stuff like Webpack or Browserify, so for those standalone build is the only option.

Luckily, this repository is not so big, so technically we can try to rewrite it to be universal w/o messing around with package.json. And in this case Bower installation will be easy.

kirill-konshin commented 7 years ago

Btw, as I said earlier, dependency xtend can be removed in favor of Object.assign.

blakeembrey commented 7 years ago

Only once you remove <= 4 in .travis.yml, which is a major breaking change, as I said earlier (https://github.com/mulesoft/js-client-oauth2/blob/master/.travis.yml#L10-L11).

kirill-konshin commented 7 years ago

Here are some requirements for universal usage in environments:

In order to make universal one-file version we have to create a UMD module, provide request, url and querystring implementations:

Let me know if you are OK with this approach in general, in this case I will start digging more.

blakeembrey commented 7 years ago

I'm not sure if you recall, but it used to be a UMD file. I don't do that anymore because it's a maintenance pain and no real benefit as an author. See https://github.com/mulesoft/js-client-oauth2/blob/783122ac12dee61a16cb5026d922140e0e6d8da4/client-oauth2.js or even https://github.com/mulesoft/js-client-oauth2/blob/94363a8f0ed0c65543f8b01fe248fd645b1ccba0/client-oauth2.js for standalone UMD files. I don't have any real desire to maintain libraries like that anymore, it really hinders the type of improvements that can be made.

blakeembrey commented 7 years ago

If there's some way to do it using modules still, let me know. But I've only ever seen UMD files implemented as a single file. It's much easier just to use browserify to build a UMD version than to write it by hand.

kirill-konshin commented 7 years ago

Those files actually don't look so bad. They could be used on client side without any modifications, especially the second one, dependency-free. I'm not sure it's the right thing to sacrifice this portability in order to use NPM modules...

it really hinders the type of improvements that can be made

Like what?

What would be your suggestion if anybody decides to use library (as it is now) on a client?

blakeembrey commented 7 years ago

The same thing I just put here: https://github.com/mulesoft/js-client-oauth2/issues/39#issuecomment-260724134.

  1. Can never add an additional file
  2. Can not trim additional content using browser field detection
  3. As a side effect of being unable to use brower field, it may use the wrong request library to executing OAuth 2.0 flows (E.g. running the flow under Electron would use XMLHttpRequest instead of the http module)
blakeembrey commented 7 years ago

I'm going to close the issue for now as it's moved in the wrong direction. I'm happy to support direct browser users, but not in a way that hinders other parties. I've never had this issue brought up in any other modules I do support, which I believe means it's pretty uncommon compared to the normal route of bundling. As for things like Bower support, I've never been successful as things change in the project but support Bower/browsers means always writing in UMD format which restricts the ways to solve issues and results in copy and paste code to make it all work. I'm not in a rush to move back to maintaining it like that, but I am happy, as mentioned, to maintain a build that outputs something suitable for these clients.

kirill-konshin commented 7 years ago

Makes sense. In this case I the only option is to have an automatic build procedure that will push code to a separate repository, which will be used for bower/browser distributions. The procedure should push build with tags, and all of this should be wired to npm publish.

I totally agree that every serious project always has some sort of a bundler. But for better adoption of this library it should still have a fallback options for less complicated projects.

blakeembrey commented 7 years ago

Yes, I suggest that fallback is using GitHub Releases.

kirill-konshin commented 7 years ago

Makes sense, but I'm not sure we can connect bower to GH Releases... We can automate releases though, I used to have a PHAR publishing procedure in one of my PHP projects...

Some reading stuff:

blakeembrey commented 7 years ago

Yeah, I looked at it a long time ago too, when I did used to try to support Bower better. However, Bower can specify the URL directly which works. Automating the release to GitHub Releases would be great.

kirill-konshin commented 7 years ago

Bower can't store releases like NPM do, users still can point to direct URL from GH Releases, but it will NOT install any sub-dependencies... So if we guarantee that Bower version will be dependency-free, it's kinda fine. And we still will not be able to register a name in their registry (because there is no place to point to).

Otherwise a separate git repo will be needed specifically to store releases (that's what people usually do). This repo could be a git submodule of the main one, btw.

Ugly as hell to me... but people do use Bower and it just can't be ignored...

kirill-konshin commented 7 years ago

Some info regarding Github releases: https://docs.travis-ci.com/user/deployment/releases/ And NPM releases: https://docs.travis-ci.com/user/deployment/releases/

These two things will allow to fully automate release process.