__spreadArrays is not defined

[perbergland]

With Meteor 1.8.2 and adornis:typescript@0.9.14 I get the following error at runtime:

.../.meteor/packages/promise/.0.11.2.hy69oz.ytuae++os+web.browser+web.browser.legacy+web.cordova/npm/node_modules/meteor-promise/promise_server.js:218
W20191115-13:18:23.853(1)? (STDERR)       throw error;
W20191115-13:18:23.854(1)? (STDERR)       ^
W20191115-13:18:23.854(1)? (STDERR) 
W20191115-13:18:23.854(1)? (STDERR) ReferenceError: __spreadArrays is not defined

for code that uses an array spread:

export const projectForReferencesListFields = tuple(
  ...partialProjectForDisplayFields,
  "forms",
  "purpose",
  "verifyWithLinkedInActive",
  "hideProjectInfoForReference",
  "hideHiringCompanyFromReference",
  "companyProfileId"
);

[perbergland]

It could very well be self-inflicted since my tsconfig.json file has a lot of flags I only understand half of. Trying again now after removing most of them.

   "target": "es5",
    "lib": ["es6","dom"],
    "incremental": true,
    "moduleResolution": "node",
    "strictNullChecks": true,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "allowSyntheticDefaultImports": true,

...

update: nope - same error with a much smaller config

[afrokick]

did you use @babel/core ?

[perbergland]

Use? Do mean adding it as a dependency?

[perbergland]

Here are the code diffs. I'm not sure who's supposed to provide the __spreadArrays function.
tsc 3.6 on the command line emits it to the top of each file where it's used.
There is no __spreadArrays implementation in app.js, at least.

// .meteor/local/build/programs/server/app/app.js

// TS 3.5.2:
exports.projectForReferencesListFields = schema_utils_1.tuple.apply(void 0, project_utils_1.partialProjectForDisplayFields.concat(["forms",
    "purpose",
    "verifyWithLinkedInActive",
    "hideProjectInfoForReference",
    "hideHiringCompanyFromReference",
    "companyProfileId"]));

// TS 3.6.3:
exports.projectForReferencesListFields = schema_utils_1.tuple.apply(void 0, __spreadArrays(project_utils_1.partialProjectForDisplayFields, ["forms",
    "purpose",
    "verifyWithLinkedInActive",
    "hideProjectInfoForReference",
    "hideHiringCompanyFromReference",
    "companyProfileId"]));

[perbergland]

OK, so __spreadArrays is implemented in tslib.js and tsc.js and a bunch of other places so why can't it be loaded? I can't say that I understand the meteor build process but could it be that it is optimized away somehow?

E.g. .meteor/local/build/programs/server/npm/node_modules/meteor/adornis_typescript-compiler/node_modules/typescript/lib/tsc.js

[perbergland]

Here's a some minimal repro steps:

meteor create minimal-typescript
cd minimal-typescript
meteor update --release 1.8.2
meteor add adornis:typescript
npm i @types/meteor --save-dev
mv server/main.js server/main.ts

in package.json, replace server/main.js with server/main.ts

replace the content of server/main.ts with:

import { Meteor } from "meteor/meteor";

export const tuple = <T extends string[]>(...args: T) => args;

export const partialProjectForDisplayFields = tuple(
  "_id",
  "company",
  "name",
  "inhouseProject",
  "status"
);

export const projectForReferencesListFields = tuple(
  ...partialProjectForDisplayFields,
  "forms",
  "purpose",
  "verifyWithLinkedInActive",
  "hideProjectInfoForReference",
  "hideHiringCompanyFromReference",
  "companyProfileId"
);

Meteor.startup(() => {
  // code to run on server at startup
});

Run meteor =>

.meteor/packages/meteor-tool/.1.8.2.18n54s7.o3dj++os.osx.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.x86_64/dev_bundle/server-lib/node_modules/fibers/future.js:280
W20191117-14:20:52.646(1)? (STDERR)                                             throw(ex);
W20191117-14:20:52.647(1)? (STDERR)                                             ^
W20191117-14:20:52.647(1)? (STDERR) 
W20191117-14:20:52.647(1)? (STDERR) ReferenceError: __spreadArrays is not defined
W20191117-14:20:52.647(1)? (STDERR)     at main.js (server/main.ts:13:52)
W20191117-14:20:52.647(1)? (STDERR)     at fileEvaluate (packages/modules-runtime.js:336:7)
W20191117-14:20:52.647(1)? (STDERR)     at Module.require (packages/modules-runtime.js:238:14)
W20191117-14:20:52.648(1)? (STDERR)     at require (packages/modules-runtime.js:258:21)
W20191117-14:20:52.648(1)? (STDERR)     at server/main.ts:25:4

[perbergland]

I have a theory of what’s going on here:
barbatus:typescript-runtime

TS 3.6 introduced a new helper method __spreadArrays and because of the way this plugin is built, typescript-runtime needs to be enhanced to export this new method in addition to the others.

https://github.com/barbatus/typescript-runtime/blob/master/typescript-helpers.js

Does this make sense @yorrd ?

[perbergland]

Here's a workaround that avoids needing to fork and republish typescript-runtime:

Create a .js file that you import from somewhere and add this as content:

import tslib from "tslib";
global.__spreadArrays = tslib.__spreadArrays;

[perbergland]

Another way to fix this is to add the following flag to tsconfig.json:

• "importHelpers": true,

that will make the generated code import "tslib" itself and then we could potentially even get rid of typescript-runtime (#4)

importHelpers was added in TS 3.4

[yorrd]

The runtime helpers are probably legacy anyways. If you want to open a PR to both remove the runtime and add the importHelpers property to the readme, go ahead.

I can see you liking the verbose error logging here, that might be configurable through babel in the official version though. Wondering if we should rather fork that in the future. You see, we're dragging along a lot of old stuff in this repo which I honestly don't fully understand. At that point our team figured it's easier to go with the predefined route.

You seem to be more than capable to understand the package though, if you want to be added as a maintainer, let's have a quick chat in dm :)

[perbergland]

Not sure how to dm from github tbh, but you can dm me on twitter - @perbergland