build fails with Allocation failed - JavaScript heap out of memory

[govis]

Getting an out of memory exception when running polymer build with 3 builds (es2015+modules, es2015 and es5 - standard configurations). All 3 builds work individually - when run 1 at a time.

<--- Last few GCs --->

[2500:00000251EB102490]   134164 ms: Mark-sweep 1337.1 (1459.1) -> 1336.6 (1461.1) MB, 2435.8 / 0.0 ms  allocation failure GC in old space requested
[2500:00000251EB102490]   137374 ms: Mark-sweep 1336.6 (1461.1) -> 1336.6 (1422.6) MB, 3208.7 / 0.0 ms  last resort GC in old space requested
[2500:00000251EB102490]   140427 ms: Mark-sweep 1336.6 (1422.6) -> 1336.6 (1422.6) MB, 3053.3 / 0.0 ms  last resort GC in old space requested

<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0000012159025879 
    1: DoJoin(aka DoJoin) [native array.js:~94] [pc=0000035D008EF3B4](this=0000011DD08022D1 ,o=00000151517294A1 ,p=496,D=0000011DD0802371 ,z=0000011DD0802431 ,y=0000011DD08023E1 )
    2: Join(aka Join) [native array.js:~119] [pc=0000035D008DE07E](this=0000011DD08022D1 ,o=00000151517294A1 ,p=496,z=0000011DD0802431 

I'm on Windows 10, node v.8.12. The node.js process approaches ~1.5GB but doesn't grow any further even as there's still a few GB of free memory available.

Thanks

[govis]

Here's another more detailed error (running latest node 11.2 on Windows 10):

<--- Last few GCs --->

[15068:00000191C5A4AF50]   134907 ms: Mark-sweep 1356.1 (1425.7) -> 1355.3 (1426.2) MB, 1445.0 / 0.0 ms  (average mu = 0.097, current mu = 0.017) allocation failure scavenge might not succeed
[15068:00000191C5A4AF50]   137036 ms: Mark-sweep 1356.4 (1426.2) -> 1355.7 (1426.7) MB, 2096.1 / 0.0 ms  (average mu = 0.048, current mu = 0.015) allocation failure scavenge might not succeed

<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 00000225CE950361]
Security context: 0x0343e559d9f1 <JSObject>
    1: updateInDeepMap(aka updateInDeepMap) [000003E2E208FA81] [C:\Users\...\AppData\Roaming\npm\node_modules\polymer-cli\node_modules\rollup\dist\rollup.js:~5923] [pc=00000225CFD2E24B](this=0x008d224025b1 ,0x03e2e208e8f9 <Object map = 000000F316B82521>,0x00b21301d3b9 ,0x03e2e208e8f9 <Object map = 000000F...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 00007FF7052FABAA v8::internal::GCIdleTimeHandler::GCIdleTimeHandler+4810
 2: 00007FF7052A0C96 uv_loop_fork+80486
 3: 00007FF7052A1BC0 uv_loop_fork+84368
 4: 00007FF70571DC6E v8::internal::FatalProcessOutOfMemory+798
 5: 00007FF70571DBA7 v8::internal::FatalProcessOutOfMemory+599
 6: 00007FF7059F6E24 v8::internal::Heap::RootIsImmortalImmovable+14788
 7: 00007FF7059ECA64 v8::internal::Heap::CollectGarbage+7556
 8: 00007FF7059EB138 v8::internal::Heap::CollectGarbage+1112
 9: 00007FF7059F4AA7 v8::internal::Heap::RootIsImmortalImmovable+5703
10: 00007FF7059F4B26 v8::internal::Heap::RootIsImmortalImmovable+5830
11: 00007FF7055B5611 v8::internal::Factory::NewFillerObject+49
12: 00007FF705D103DA v8::internal::StoreBuffer::StoreBufferOverflow+26826
13: 00000225CE950361

Adding "--max_old_space_size=8192" to node command line arguments arguments in polymer.cmd file as follows lets the process to grow to about 2.5GB and the build succeeds

@IF EXIST "%~dp0\node.exe" (
  "%~dp0\node.exe" "--max_old_space_size=8192" "%~dp0\node_modules\polymer-cli\bin\polymer.js" %*
) ELSE (
  @SETLOCAL
  @SET PATHEXT=%PATHEXT:;.JS;=;%
  node "--max_old_space_size=8192" "%~dp0\node_modules\polymer-cli\bin\polymer.js" %*
)

[IchordeDionysos]

We are having the same issue... What can we do about it?

Building locally won't work even on a 16GB machine without anything else to do. Building on our CI server works sometimes.

[JoeyBG]

Same here.

Here's an example stack trace

<--- Last few GCs --->

[24066:0x32a78b0]   201862 ms: Scavenge 1342.5 (1421.4) -> 1342.2 (1422.4) MB, 3.3 / 0.0 ms  (average mu = 0.162, current mu = 0.033) allocation failure
[24066:0x32a78b0]   202509 ms: Mark-sweep 1342.8 (1422.4) -> 1342.6 (1422.4) MB, 645.9 / 0.0 ms  (average mu = 0.088, current mu = 0.010) allocation failure scavenge might not succeed

<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0xe6662f4fb5d]
Security context: 0x096974d1d969 <JSObject>
    1: /* anonymous */ [0x8a9dfb7d219] [/home/jbg/webapp/app/node_modules/@babel/traverse/lib/index.js:~87] [pc=0xe6663c1f5c8](this=0x33568c3fd661 <JSFunction traverse (sfi = 0x8a9dfb32969)>,0x11235ed78199 <Node map = 0x1a51faaa4171>,0x08a9dfb7fbe1 <Object map = 0x19933309c471>,0x34fd001deb19 <Scope map = 0x19933309c241>,0x37f75f6db091 <Object map = 0x1993330...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x90af00 node::Abort() [polymer]
 2: 0x90af4c  [polymer]
 3: 0xb05f9e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [polymer]
 4: 0xb061d4 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [polymer]
 5: 0xf0c6f2  [polymer]
 6: 0xf0c7f8 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [polymer]
 7: 0xf18f88 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [polymer]
 8: 0xf19b1b v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [polymer]
 9: 0xf1c851 v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [polymer]
10: 0xee6834 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [polymer]
11: 0x11a0672 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [polymer]
12: 0xe6662f4fb5d
Aborted (core dumped)
error Command failed with exit code 134.

[zevisert]

Hitting this too. I can pin it down to a dynamic import of tiff.js/tiff.min.js in the project I'm working on. Tiff.js is a HUGE file generated from LibTIFF's C sources using Emscripten for loading TIFF files in the browser, I think polymer is trying to minify it or something, although I get the same results if I specify 'node_modules/tiff.js/tiff.min.js' in the extraDependencies or excludes of polymer.js build configurations.

[adi130987]

Any updates on this? I got the same issue :|

[pawelkrystkiewicz]

Same here

[djlauk]

I was facing the same issue. In our polymer.json we have 2 build configurations (I don't even know, why):

"builds": [
    {
      "name"  : "default",
      "preset": "es5-bundled",
      "bundle": {
        "excludes": ["configuration-mixin.js", "src/daq-search-query-worker.js"]
      }
    },
    {
      "name"  : "default1",
      "bundle": {
        "excludes": ["configuration-mixin.js", "src/daq-search-query-worker.js"]
      },
      "addServiceWorker": false
    }
  ]

For me, as well, when I run specific builds, one at a time, it works fine, but running polymer build without --name ... will create this error.

I don't know, if this matters, but the project was a Polymer 2 project, which we are porting to Polymer 3, i.e. the code is based on PolymerElement not LitElement.

[adi130987]

@djlauk try this:

export NODE_OPTIONS=--max_old_space_size=4096
polymer build

My team had this issue after upgrading from Polymer 2 to Polymer 3 and this solution worked for us.

[djlauk]

Thanks, @adi130987. This workaround worked as well, but it still takes very long:

$ time polymer build
info:   Clearing build/ directory...

... some warnings ...

info:   (default1) Building...
[BABEL] Note: The code generator has deoptimised the styling of undefined as it exceeds the max of 500KB.
info:   (default) Building...
info:   (default) Build complete!
info:   (default1) Build complete!

real    18m59.162s
user    20m44.079s
sys 0m9.745s

While each of the individual named builds runs a lot faster:

$ time polymer build --name default
info:   Clearing build/ directory...
info:   (default) Building...
[BABEL] Note: The code generator has deoptimised the styling of undefined as it exceeds the max of 500KB.

... some warnings ...

info:   (default) Build complete!

real    0m25.081s
user    0m34.406s
sys 0m1.926s

and

$ time polymer build --name default1
info:   Clearing build/ directory...
info:   (default1) Building...
[BABEL] Note: The code generator has deoptimised the styling of undefined as it exceeds the max of 500KB.

... some warnings ...

info:   (default1) Build complete!

real    0m25.371s
user    0m34.696s
sys 0m2.043s

I hope this information can help someone to circle in on the cause of this issue a bit quicker. Here are some more notes / thoughts:

• I am aware that the names "default" and "default1" are not great. (Like I said, I don't even know, why we have the two. It's just what was already there when I was put on the project.)
• The warnings that I skipped in the output are the same for all the builds, combined or individual. So I consider them irrelevant to this issue. (They are about not being able to resolve a class reference which is the parameter to the mixin functions in our code.)

Also maybe worth noting are the following things I noticed about the combined polymer build (top output):

• For the combined build, the warnings come before the output info: (default1) Building...; for the individual builds the order is reversed.
• The output of build "default" is nested inside the output of build "default1". I.e. judging from the output:
  • Build "default1" starts.
  • Build "default" starts.
  • Build "default" ends.
  • Build "default1" ends.
• For the longest time there is no visible activity at all, then everything seems to have been finished at once:
  • Output starts at "normal progress speed" but there is a long pause right after the warnings for most of the remaining time.
  • The build of "default" seemed to have taken the same amount of time (noticed from the corner of my eye)
    • There was only a short amount of time between info: (default) Building... and info: (default) Build complete!
  • Right afterwards there was the notice info: (default1) Build complete!
• I've repeated to run polymer build multiple times, each run giving similar results (a few seconds faster / slower)

[ghost]

polymer build --name whatever doesn't run the build config called "whatever", it just builds with the defaults & names the output "whatever".

Someone opened https://github.com/Polymer/tools/issues/606 for that functionality

[logicalphase]

@djlauk - does your polymer.json include:

"moduleResolution": "node", "npm": true

If not and you add it does it make any difference?

[djlauk]

@hyperpress Yes, the polymer.json has both options set this way:

{
  //...
  "moduleResolution": "node",
  "npm": true,
  // ...
}

[robertavram]

Running into the same issue here, anyone any tips or tricks on this? we're being killed on build/deploy times/resources. :(

[logicalphase]

Delete your node_modules folder and package-lock.json. Then, do 'polymer install' and 'polymer serve'. If all works run 'polymer build'.

Make sure that the old modules folder and lock file are deleted, not just in trash.

If that doesn't solve it. Please post a full trace, along with environment (Windows, Mac, Linux, OS version, Node and NPM version, hardware RAM, CPU, Disk space available.

I'm thinking we should just start from the basics and try a figure out what's causing the fault from there.

[robertavram]

Tried it all :) @adi130987 @acory have been leading on this one from our side... for context here's one of the repo polymer.json and package.json: https://github.com/unicef/etools-partnership-management/blob/prepare-for-deploy/polymer.json https://github.com/unicef/etools-partnership-management/blob/prepare-for-deploy/package.json

whether running in circleCi, locally docker , or locally (2016 Macbook Pro | High Sierra | 16gb Ram | 2.9GHz I7) running into the same issue, either memory allocation or if we export NODE_OPTIONS=--max_old_space_size=4096 it takes 20 min.

the repo is open source if anyone is inclined to help you might be able to reproduce this if you clone it, go to prepare-for-deployment branch and run npm run build after installing node packages. We recently moved from poly2 to poly3.

Thanks a million, in advance :)

The trace is gigantic.. I would take all the space github allotted in their db for comments :)

[ghost]

There are 3 builds in that polymer.json, have you tried running polymer build with one build at a time in the builds array? Do all of the builds behave this way when they are the only one in the polymer.json or is there a single culprit? What about 2 builds at a time? etc

On Fri, Mar 29, 2019, 9:30 AM Robert Avram notifications@github.com wrote:

Tried it all :) @adi130987 https://github.com/adi130987 @acory https://github.com/acory have been leading on this one... for context here's one of the repo polymer.json and package.json:

https://github.com/unicef/etools-partnership-management/blob/prepare-for-deploy/polymer.json

https://github.com/unicef/etools-partnership-management/blob/prepare-for-deploy/package.json

whether running in circleCi, locally docker , or locally (2016 Macbook Pro | High Sierra | 16gb Ram | 2.9GHz I7) running into the same issue, either memory allocation or if we export NODE_OPTIONS=--max_old_space_size=4096 it takes 20 min.

the repo is open source if anyone is inclined to help you might be able to reproduce this if you clone it, go to prepare-for-deployment branch and run npm run build after installing node packages. We recently moved from poly2 to poly3.

Thanks a million, in advance :)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Polymer/tools/issues/757#issuecomment-478063598, or mute the thread https://github.com/notifications/unsubscribe-auth/AVLM4bB8LI2wiZfSKHVdPE1eiewMKVNRks5vbj-lgaJpZM4X6dFl .

[logicalphase]

I cloned a copy and what I'm seeing on install is that your repo is referencing Polymer 2 components which rely on bower for HTML Imports.

You're referencing pmp/app-shell.htmlin polymer.json, and that file references Polymer 2 files in bower_components so obviously the app is setup to run on Polymer 2. package.json doesn't reference any Polymer 3 packages or deps.

Is this the correct repo? Perhaps you can explain this in more detail because this is not a standard polymer 3 project upgraded from polymer 2.

[acory]

@hyperpress The Polymer 3 version is on upgrade--polymer3 branch

[logicalphase]

So, I downloaded the correct branch and tried several build versions and tests. There is definitely something in the tsc build process to polymer build that it's unhappy about. There's the dynamic imports that get non-literal warnings , but then, really no matter what I've tried from one preset build with minimal options to a bunch of other trial and errors, everything hangs up badly after it clears the build directory.

I'm running this on a 24 core with a half a gig of RAM workstation with Ubuntu Linux 18.10. There's not a lack of horsepower involved here. Here's the last one I tried (just the esm build) and it did complete the build in about 50 seconds:

polymer.json.txt

If I add all the builds back in for esm, es6, and es5 the process results in a core dump with the following stack trace:

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x9193974fc5d]
    1: StubFrame [pc: 0x9193970a111]
    2: ConstructFrame [pc: 0x91939709cc4]
Security context: 0x0a397d81d9b1 <JSObject>
    3: getScope [0x103c5bc063e1] [/home/john/.nvm/versions/node/v11.11.0/lib/node_modules/polymer-cli/node_modules/@babel/traverse/lib/path/index.js:~142] [pc=0x9193a3b087a](this=0x0e6a156cb731 <NodePath map = 0x3b860f267f61>,0x0e6a156ca829 <Scope map = 0x3b860f267bf1>)
    4: visi...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

Writing Node.js report to file: report.20190329.202431.22581.001.json
Node.js report completed
 1: 0x959570 node::Abort() [polymer]
 2: 0x95a25e node::OnFatalError(char const*, char const*) [polymer]
 3: 0xb3735e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [polymer]
 4: 0xb37594 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [polymer]
 5: 0xf36bd2  [polymer]
 6: 0xf36cd8 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [polymer]
 7: 0xf433f8 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [polymer]
 8: 0xf43f0b v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [polymer]
 9: 0xf46c41 v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [polymer]
10: 0xf10e74 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [polymer]
11: 0x11c72be v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [polymer]
12: 0x9193974fc5d 
Aborted (core dumped)

If it were me, I think I'd move all this into webpack, maybe using @anoblet my-project setup as an example. His is quite fast and he's using a similar TS schema to yours. But there might be someone a lot smarter than I am with this who will see something I don't. Wish I could be of more help, but I'm stumped at this point.

[bastienarm]

Same problem here since this morning

[8952:0000020F1954BA10] 95246 ms: Scavenge 1317.9 (1436.2) -> 1307.5 (1439.7) MB, 12.6 / 0.0 ms (average mu = 0.105, current mu = 0.054) allocation failure [8952:0000020F1954BA10] 95330 ms: Scavenge 1320.5 (1439.7) -> 1309.8 (1442.7) MB, 12.4 / 0.0 ms (average mu = 0.105, current mu = 0.054) allocation failure

<--- JS stacktrace --->

==== JS stack trace =========================================

0: ExitFrame [pc: 000002909E95C5C1] Security context: 0x0229fb79e6e1 1: word [0000014F23E32009] [C:\Users\Bastien\AppData\Roaming\npm\node_modules\polymer-cli\node_modules\babel-generator\lib\printer.js:~127] [pc=000002909F55D173](this=0x00c5556022c1 ,str=0x0122b0fff9c1 <String[5]: value>) 2: Identifier [0000014D5577EC61] [C:\Users\Bastien\AppData\Roaming\npm\node_modules\polymer-cl...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory 1: 00007FF7DC6FECE5 2: 00007FF7DC6D8196 3: 00007FF7DC6D8BA0 4: 00007FF7DC968D5E 5: 00007FF7DC968C8F 6: 00007FF7DCEA69D4 7: 00007FF7DCE9D137 8: 00007FF7DCE9B6AC 9: 00007FF7DCEA4627 10: 00007FF7DCEA46A6 11: 00007FF7DCA47767 12: 00007FF7DCADF44A 13: 000002909E95C5C1

I don't know why, but when changing the head on my git repo and doing a git reset -fd will make the build works sometimes...

[kr05]

Just ran into this problem today. Running it on Cloud Build. It was running fine this morning, which is the weirdest part.

Here's the relevant part of the logs:

Finished Step #1 - "Polymer build"
Step #1 - "Polymer build": 8: 0x18e979842fd
Step #1 - "Polymer build": 7: v8::internal::Runtime_GrowArrayElements(int, v8::internal::Object**, v8::internal::Isolate*) [polymer]
Step #1 - "Polymer build": 6: 0xd7fc13 [polymer]
Step #1 - "Polymer build": 5: v8::internal::Factory::NewUninitializedFixedArray(int) [polymer]
Step #1 - "Polymer build": 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [polymer]
Step #1 - "Polymer build": 3: v8::Utils::ReportOOMFailure(char const*, bool) [polymer]
Step #1 - "Polymer build": 2: 0x8cbf4c [polymer]
Step #1 - "Polymer build": 1: node::Abort() [polymer]
Step #1 - "Polymer build": FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
Step #1 - "Polymer build": 
Step #1 - "Polymer build": 2: word [/usr/local/lib/node_modules/polymer-cli/node_modules...
Step #1 - "Polymer build": 1: _append [/usr/local/lib/node_modules/polymer-cli/node_modules/babel-generator/lib/buffer.js:~94] [pc=0x18e981edd60](this=0xd186942e5d1 <Buffer map = 0x1c3aa4e7a759>,str=0x19cbab67c0c9 <String[1]: >,line=8265,column=63,identifierName=0xe5607f02201 <null>,filename=0x1fc578f82501 <String[31]: file:///workspace/src/my-app.js>)
Step #1 - "Polymer build": Security context: 0x19cbab625879 <JSObject>
Step #1 - "Polymer build": 
Step #1 - "Polymer build": ==== JS stack trace =========================================
Step #1 - "Polymer build": 
Step #1 - "Polymer build": <--- JS stacktrace --->
Step #1 - "Polymer build": 
Step #1 - "Polymer build": 
Step #1 - "Polymer build": [1:0x2da34a0] 376761 ms: Mark-sweep 1342.6 (1477.2) -> 1342.6 (1473.2) MB, 3490.1 / 0.0 ms last resort GC in old space requested
Step #1 - "Polymer build": [1:0x2da34a0] 373270 ms: Mark-sweep 1342.7 (1525.2) -> 1342.6 (1477.2) MB, 3452.2 / 0.0 ms last resort GC in old space requested
Step #1 - "Polymer build": [1:0x2da34a0] 369817 ms: Mark-sweep 1342.9 (1525.2) -> 1342.7 (1525.2) MB, 3535.3 / 0.0 ms allocation failure GC in old space requested
Step #1 - "Polymer build": 
Step #1 - "Polymer build": <--- Last few GCs --->
Step #1 - "Polymer build": 
Step #1 - "Polymer build": info:    Clearing build/ directory...

[kr05]

I was able to "fix" the problem by removing the bundle=true property from my polymer.json file. I don't consider it truly fixed because I still haven't discovered the root cause, but it's a decent workaround to get my project deployed. I compared the last successful commit with the first failed build, and I can't see anything that would cause the bundler to fail.

[Pupix]

I encountered this problem too. Seems to be because there's no tree-shaking from what I can tell. Importing modules (my problem is with date-fns) like this:

const { startOfDay, endOfDay } from 'date-fns'

causes the whole date-fns library to be loaded and run out of memory for some reason. Sometimes it doesn't even compile it correctly and I get missplaced imports error of the like my-app.js doesn't export isProtectedWeekYearToken and such, which I am not even directly using.

Importing functions one by one solved the problem for me. Like this:

const startOfDay from 'date-fns/startOfday';
const endOfDay from 'date-fns/endOfday';

Only files needed by those 2 functions get imported and everything builds smoothly.

[adi130987]

@Pupix great...

lodash has this issue too. In our project we used to do imports like this:

import { isNil, isObject} from 'lodash'

or even worse

import _ from 'lodash', not paying attention to build performance.

After all lodash imports were updated like this:

import isNil from 'lodash/isNil';
import isObject from 'lodash/isObject';

build time improved with 50%;

[kr05]

Well my fix stopped working, unfortunately. I also tried rewriting some of my imports, but it didn't help at all. Anyone have an alternative to using polymer-cli for building a polymer/lit-element project? It's very frustrating how this problem seems to arise for no apparent reason.

[bastienarm]

Well my fix stopped working, unfortunately. I also tried rewriting some of my imports, but it didn't help at all. Anyone have an alternative to using polymer-cli for building a polymer/lit-element project? It's very frustrating how this problem seems to arise for no apparent reason.

Since the beginning i use bundle=false in my polymer.json file. By adding "--max_old_space_size=8192", the process don't take more than 1go in my computer ...

I found which file and where the builder fails (in fact, i'm not sur, but i think) I have a big file with a very big switch...case (around 20 switch), in every switch a document.createElement.

If i comment the document.createElement, it's better, but i don't know why ...

it's like polymer try to run all the code before parsing it ....

[kr05]

But that removes a big benefit to using polymer-cli. I'm currently attempting to build an alternative build process using rollup. I haven't been too successful, but I'll definitely update once I make some progress.

On Tue, Jul 2, 2019, 10:58 PM bastienarm notifications@github.com wrote:

Well my fix stopped working, unfortunately. I also tried rewriting some of my imports, but it didn't help at all. Anyone have an alternative to using polymer-cli for building a polymer/lit-element project? It's very frustrating how this problem seems to arise for no apparent reason.

Since the beginning i use bundle=false in my polymer.json file. By adding "--max_old_space_size=8192", the process don't take more than 1go in my computer ...

I found which file and where the builder fails (in fact, i'm not sur, but i think) I have a big file with a very big switch...case (around 20 switch), in every switch a document.createElement.

If i comment the document.createElement, it's better, but i don't know why ...

it's like polymer try to run all the code before parsing it ....

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Polymer/tools/issues/757?email_source=notifications&email_token=AC2JDEGEM6EC3ZEGX4IWLMDP5Q5XPA5CNFSM4F7J2FS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZDLJKQ#issuecomment-507950250, or mute the thread https://github.com/notifications/unsubscribe-auth/AC2JDEHVWK6FVI53V46HXUDP5Q5XPANCNFSM4F7J2FSQ .

[rpapeters]

Just to let you know; for me this issue came from (module) import 'sinon/pkg/sinon-esm.js' After removing the import all worked well for me.

[ales6164]

By my experience the most important factor in build time is number of dependencies in package.json ("devDependencies" doesn't matter). Any other dependency than polymer, webcomponents, lit-element, pwa-helpers and redux dramatically increases build time for me.

[kr05]

Ever since I migrated to rollup, I haven't experienced any issues whatsoever. This comes from someone that had using polymer-cli for over 2 years.

[Anid4u2c]

Ever since I migrated to rollup, I haven't experienced any issues whatsoever. This comes from someone that had using polymer-cli for over 2 years.

@kr05 Would you be willing to paste a sample of your implementation?

[kr05]

My setup is due for an update, but I'll link a previous answer where I posted my implementation.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[sidverma32]

Steps to resolve memory leaks: StackOverFlow

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.