Installing via package managers, usage with webpack and react

[sarincasm]

Is there a way to install and use this lib using npm. I wish to use it with webpack/react and do not want to add an additional script tag just for this lib.
All the examples and guides for the lib want me to include this directly in my html <script type="text/javascript" src="https://apis.google.com/js/api.js?onload=onApiLoad"></script>, which feels really restrictive.

[TMSCH]

@eelsweb this is currently not possible by design. The reason is that the libraries loaded through gapi.load are not versioned, they are constantly updated. Package managers follow a versioned model which is not compatible.

However, we could provide a simple package which would take care of loading the https://apis.google.com/js/api.js script for you, thus providing (asynchronously) gapi.load and by extension all gapi libraries. Would that solve your problem? Remember that such solution would not allow you to bundle in your own JS the gapi libraries you are using. They will always be loaded asynchronously.

[sarincasm]

For now, I have simply made a local copy of the file https://apis.google.com/js/api.js and am importing that in my code, loading gapi libs asyncly.
If you do not intend to change this design pattern in the near future, then I guess we should close this issue. Though it would be nice to include a few instructions on how to best use this lib while bundling/usage with webpack etc.

[TMSCH]

@eelsweb keeping a local copy of this script is highly discouraged. It will always load a specific version of the gapi libraries that correspond to when you downloaded this script*. This means you won't be able to get new features, bug fixes, or any updates. We could provide a package as I described earlier, so let's keep this issue open.

*When I said unversioned earlier, I was slightly incorrect. The libraries are versioned, and new versions are pushed daily - however, there is no way for apps to control which version they are getting, they will always get the latest one. By keeping a local cache of api.js, it will use the version number contained in it and will always download that version. Let me know if that makes sense!

[sarincasm]

I intend to download the script as part of the build process, so the app gets the new version every time there is a release. This way, I can update the js file while developing, and ensure there is zero chance of anything breaking while in production. I believe providing a package will work exactly the same way, because a particular version of the pkg will be downloaded, and will stay that way until upgraded in the app.

Thanks for your help.

[TMSCH]

The package I was mentioning would load asynchronously the https://apis.google.com/js/api.js file so it will always use the latest version, independent of the release cycle of your app. Your method is relatively safe too, especially if you only use gapi.auth2 (and not gapi.client), but depends on the frequence of your release cycles.

[vohzd]

@TMSCH I've also run into this issue as experienced by @eelsweb - I notice you offer you could provide a package via npm. Could I take you up on that offer?

[TMSCH]

@vohzd I could but cannot provide any ETA, so I would not count on it in the short term.

[vohzd]

Thank you - I found a workaround anywho with using https://github.com/ryanjohnston/Load-Google-API which let's you import gapi.

[sarincasm]

my solution with React right now, if someone is interested -

componentDidMount() {
	const gapiScript = document.createElement('script')
	gapiScript.src = 'https://apis.google.com/js/api.js?onload=onGapiLoad'
	window.onGapiLoad = function onGapiLoad() {
		gapi.load('auth', {'callback': onAuthApiLoad})
		function onAuthApiLoad() {
			gapi.auth.init()
		}
	}
	document.body.appendChild(gapiScript)
}

[alinnert]

I just found this documentation page: https://developers.google.com/identity/protocols/OAuth2UserAgent

It describes how to authenticate, get access tokens and use Google APIs using nothing but HTTP requests (when you click on the "OAUTH 2.0 ENDPOINTS" tab above the code examples). This way one could bypass api.js entirely and write their own mini library (or a full-featured if you're crazy). I haven't tried it but I'm going to do that the next days.

[dfederm]

@TMSCH Since the code looks fairly stable now (no longer being "constantly updated"), can we get an npm package? Ideally multiple packages, one for each api, but with tree shaking in webpack now it'd be fine to just have 1 package with everything. In fact, there would be no need to worry about the gapi.load call anymore if it was just one big package.

[TMSCH]

@dfederm this repository does not contain the code of the gapi libraries. gapi libraries are still constantly updated, and there is a reason it is served dynamically through gapi.load rather than by downloading a NPM package. These libraries interact with Google APIs and these APIs change, being able to always have clients fetch an up-to-date version makes sure that the libraries work.

There is no plan to provide NPM package for each independent gapi libraries.

[dfederm]

@TMSCH Ah, I just assumed the "Google API Client Library for JavaScript" would contain... the Google API Client Library for JavaScript.

I'm not really sure I follow your reasoning. Are you implying that the Google APIs themselves are completely unstable and unversioned and could break at anytime? Yet somehow the JS client which is just a wrapper around these APIs won't break (even when downloaded dynamically people still need a stable interface to code against)?

If you're serving JS dynamically like that, obviously you can't make breaking change to the public interface of that as it will just break people out of band. So let's assume the public interface of the JS client is stable, or at least non-breaking.

Now for the API aspect, when I view the Google APIs, they seem to be versioned and they imply that they can be called directly, without the use of a client. So based on that, I think we can assume that the API layer is also non-breaking.

So if the JS client has a non-breaking interface, and the APIs have to be non-breaking as well, I'm not sure what's left of the argument that the JS client is constantly changing and an npm package can't be made of it. The implementation of how the client makes the API calls under the covers can change I guess, but as I noted, both the JS interface and API surface area have to be somewhat stable in order to not just randomly break people who are using it.

[TMSCH]

I was actually misleading. Now that gapi.client use discovery docs, we are untied from the server APIs changes. The core issue that prevents us to create true npm package containing the libraries code is that the core infrastructure and design of gapi libraries is unversioned. NPM is versioned, so it's incompatible.

The best we could provide is npm packages that are just thin libraries that call inject the proper api.js file and perform gapi.load of the requested libraries.

[bsittler]

Using old/cached/package-managed versions of the JS client is not supported.

@dfederm actually the interfaces for some parts do change backwards-incompatibly, but on timeframes that allow new JS client versions to roll out (e.g. weeks.) The JS build fingerprint in the client is linked to JS build fingerprint inside some IFRAMEs, and using an old/cached/package-managed JS client can lead to breakage once the old JS build fingerprint evaporates on the server side. See e.g. #204