Clasp: ES Module Support

[grant]

Expected Behavior

Note: This is still more of an idea than an actual issue. The design needs to be though out a bunch more.

You should be able to separate code with ES modules.

Use require, import, etc.

Actual Behavior

All variables/functions are globally scoped like the web.

Solution

Use a modern JavaScript bundler (webpack) under the hood. Make things "just work".

This would allow for better library support in the future.

Caveats

• We may have to support only TS for module support initially.
• In Apps Script, all methods are exposed by default. We may have to manually expose some methods.

Links

• TS Transpiler ts-loader
• History
• Web support

[mainmode1]

gas-basic-scaffold 🙂

[grant]

Cool! There's a lot of complicated stuff going on (as is normal in the web world these days).
If there's anything clasp can do to make building these scaffolds simpler, LMK!

[mainmode1]

Been thinking about this. Not really that complex once the boilerplate is in place. Most of the code in that repo is just proof-of-concept demonstrator. You could simply have one file, src/index.js (along with the manifest):

global.hello = () => {
  console.log('Hello world.');
  return 'Done.';
};

And it would create in dist/:

main.js  730 bytes
webpack-runtime.js  3.7 KiB
appsscript.json 326 bytes

main.js:

function hello() {
}(function(e, a) {
  for (var i in a) e[i] = a[i];
})(this, (this["webpackJsonp"] = this["webpackJsonp"] || []).push([ [ 0 ], [ function(module, exports, __webpack_require__) {
  module.exports = __webpack_require__(1);
}, function(module, exports, __webpack_require__) {
  "use strict";
  (function(global) {
    global.hello = function() {
      console.log("Hello world.");
      return "Done.";
    };
  }).call(this, __webpack_require__(2));
}, function(module, exports) {
  var g;
  g = function() {
    return this;
  }();
  try {
    g = g || Function("return this")() || (1, eval)("this");
  } catch (e) {
    if (typeof window === "object") g = window;
  }
  module.exports = g;
} ], [ [ 0, 1 ] ] ]));

...and you could still take advantage of imports, require, ES6/ES7, etc. The real power comes with leveraging NpmJS modules in your project (without resorting to eval() tricks), which is why I set it up. I've toyed with writing my own require-esque module loaders, caching/eval fetched code, etc. but this is the most robust solution.

I suppose you could transpile and bundle the module loader by calling babel+webpack programmatically from within clasp. I'll see if that works (but I have to stop neglecting my day job -ha).

[fossamagna]

Similar case. There is Yeoman generator for Apps Script.
https://github.com/fossamagna/generator-gas

[grant]

This is a larger issue than clasp itself so I'm going to move this to the Nice To Have bucket. I think natively running Node would be better than bundling like this.

[PopGoesTheWza]

PR #583 documents possible workaround: https://github.com/google/clasp/blob/master/docs/typescript.md

[GitTom]

Google is going to be releasing a V8 runtime for GAS which I assume will resolve this ES Module issue.

It was first mentioned officially in summer of 2018 (to best of my knowledge) so my guess is that it will come out in some form at Google Cloud Next ’19 in April (I have no inside knowledge).

I'm not saying that resolves this issue - it could well be a long time before it goes GA - but I think it it useful context.

[wittekm]

Google Cloud Next 2019 has come and gone, with (as far as I know) no mention of the V8-ification. Where would be the best place to track progress or announcements on this?

[PopGoesTheWza]

For the moment being, modules (any flavour, es, commonjs, you name it) make no sense in a Google Apps Script context.
For code isolation, I use typescript namespace

I've been investigating on another Typescript approach which would have ts2gas to work at the project level (i.e. tsconfig.json) rather than individual files. This should enable many nice features.

• multiple tsconfig (project references, incremental build, etc.)
• triple slash directives support
• outFile support (many .ts files to a single .gs file)

I will try to PR a POC in the weeks to come

[rielzzapps]

But what about dependencies?

Op vr 19 apr. 2019 19:35 schreef PopGoesTheWza [e-mail]:

For the moment being, modules (any flavour, es, commonjs, you name it)
make no sense in a Google Apps Script context.
For code isolation, I use typescript namespace

I've been investigating on another Typescript approach which would have
ts2gas to work at the project level (i.e. tsconfig.json) rather than
individual files. This should enable many nice features.

• multiple tsconfig (project references, incremental build, etc.)
• triple slash directives support
• outFile support (many .ts files to a single .gs file)

I will try to PR a POC in the weeks to come

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/google/clasp/issues/325#issuecomment-484966271, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACITFWCXY355GH7X6NLQ2K3PRH7GBANCNFSM4FVHVCTQ
.

[PopGoesTheWza]

@rielzzapps I am unsure what you mean exactly by dependencies.

What I have in mind is more about code isolation/organisation and better support of typescript compilation features.

Take a look at how Typescript source itself is organised.

Also this chapter of typescript documentation might be clearer than my english https://www.typescriptlang.org/docs/handbook/project-references.html

[GitTom]

Yes, I am surprised that we didn't see an announcement (eg. a public beta release) of the v8 runtime at Next, but there is still potential for it in the short term: Google I/O which is May 7-9.

If they don't announce anything at I/O than I guess all bets are off, but I think they will.

[PopGoesTheWza]

Request For Comments

I have put up a repository which illustrate and document what I believe is the best alternative to the lack of support for module.
https://github.com/PopGoesTheWza/ts-gas-project-starter

I am very interested in your comments, critics and feedback

[fabacab]

@PopGoesTheWza:

I am unsure what you mean exactly by dependencies.

I think what @rielzzapps means (please correct me if I'm wrong), is that it would be nice to have the capability of using NPM packages as a dependency in a Google Apps Script project.

I found this thread today while trying to setup a Meetup API integration with a Google Spreadsheet. There is the handy meetup-api NPM module and when using clasp for local GAS development, I'd love to be able to do…

npm install --save meetup-api
# …write some GSheet and Meetup API integration code, and then…
npx webpack
npm run push # Executes `cd dist && clasp push`

…instead of having to write (or port) the Meetup API library code to GAS-compatible JavaScript myself.

Instead of doing that, at the moment, I am lost in a deep, dark well of adding Babel to my Webpack configuration in order to transpile my meetup-api dependency into a JavaScript 1.6/ECMAScript 3 compatible bundle so that I can use it in my GAS code. I'm no Babel expert so I'm having a bit of trouble with this. Too much more banging my head against the wall and I'll probably just write the GAS port directly instead of struggling with an ever more complex build toolchain.

Thing is, simply bundling NPM modules was not so difficult (I have it working with the front-matter package by using an extremely simple Webpack config), but this quickly gets much more complex if the "dependency" needs to be transpiled with Babel.

I'll have a look at @mainmode1's gas-basic-scaffold next, since that looks like it might point me in the right direction for the moment, but it would be really, really nice if rumors of Google Apps Scripts's JavaScript engine modernization turned out to be true.

[wittekm]

Node modules from GAS is probably a non-starter for now since

• only URLFetchApp is supported for http calls
• GAS is pseudo-es5, not node, not real es5, and isn't on V8 quite yet.

On Tue, Jan 28, 2020, 12:00 PM Meitar M. [e-mail] wrote:

@PopGoesTheWza https://github.com/PopGoesTheWza:

I am unsure what you mean exactly by dependencies.

I think what @rielzzapps https://github.com/rielzzapps means (please
correct me if I'm wrong), is that it would be nice to have the capability
of using NPM packages as a dependency in a Google Apps Script project.

I found this thread today while trying to setup a Meetup API integration
with a Google Spreadsheet. There is the handy meetup-api NPM module
https://www.npmjs.com/package/meetup-api and when using clasp for local
GAS development, I'd love to be able to do…

npm install --save meetup-api

…write some GSheet and Meetup API integration code, and then…

npx webpack

npm run push # Executes cd dist && clasp push

…instead of having to write (or port) the Meetup API library code to
GAS-compatible JavaScript myself.

Instead of doing that, at the moment, I am lost in a deep, dark well of
adding Babel to my Webpack configuration in order to transpile my
meetup-api dependency into a JavaScript 1.6/ECMAScript 3 compatible
bundle so that I can use it in my GAS code. I'm no Babel expert so I'm
having a bit of trouble with this. Too much more banging my head against
the wall and I'll probably just write the GAS port directly instead of
struggling with an ever more complex build toolchain.

Thing is, simply bundling NPM modules was not so difficult (I have it
working with the front-matter package
https://github.com/tech-learning-collective/enrollment-automation/blob/63384915b1cc396585acdb5a10bc0f9628588049/src/lib.js#L1
by using an extremely simple Webpack config
https://github.com/tech-learning-collective/enrollment-automation/blob/63384915b1cc396585acdb5a10bc0f9628588049/webpack.config.js#L6-L8),
but this quickly gets much more complex if the "dependency" needs to be
transpiled with Babel.

I'll have a look at @mainmode1 https://github.com/mainmode1's
gas-basic-scaffold
https://github.com/google/clasp/issues/325#issuecomment-421608733 next,
since that looks like it might point me in the right direction for the
moment, but it would be really, really nice if rumors of Google Apps
Scripts's JavaScript engine modernization turned out to be true.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/google/clasp/issues/325?email_source=notifications&email_token=AAENHYT4BD25YRKH25OF5OTRACFFVA5CNFSM4FVHVCT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKEWATA#issuecomment-579428428,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAENHYSG5MSVHFP3C4RHGWDRACFFVANCNFSM4FVHVCTQ
.

[tomdavidson]

https://developers.google.com/apps-script/guides/v8-runtime

[wittekm]

Just to make sure, has this been tested with Gmail Addon/GSAO at all? I tried adding runtimeVersion: "V8" and it results in the supremely debuggable

Error: We're sorry, a server error occurred. Please wait a bit and try again. [line: 0, function: , file: undefined]

(if there's a better place to report that, happy to go there :) )

[PopGoesTheWza]

@tomdavidson v8 runtime is great news but... there's a warning in the page you kinked:

Caution: ES6 modules are not yet supported.

[PopGoesTheWza]

@wittekm Sorry but I am not familliar with this Gmail Addon/GSAO. Still the homepage for this add-on is likely the best place to report an issue.

[wittekm]

Gmail addon and GSuite Add-on are Google's platforms to build apps that
live in the right-side drawer of Gmail. It's an official platform that runs
on Apps Script.

On Thu, Feb 6, 2020, 7:44 PM PopGoesTheWza [e-mail] wrote:

@wittekm https://github.com/wittekm Sorry but I am not familliar with
this Gmail Addon/GSAO. Still the homepage for this add-on is likely the
best place to report an issue.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/google/clasp/issues/325?email_source=notifications&email_token=AAENHYTMXECGLACUMAL3WGTRBTKLBA5CNFSM4FVHVCT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELBT4XI#issuecomment-583220829,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAENHYWHV4OYQITNQ3XZIO3RBTKLBANCNFSM4FVHVCTQ
.

[tomdavidson]

@PopGoesTheWza not an announcement that all our problems go away or that this issue should be closed.