Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ForkTsCheckerWebpackPlugin Configuration #127

Open
MarZab opened this issue Aug 12, 2020 · 17 comments
Open

ForkTsCheckerWebpackPlugin Configuration #127

MarZab opened this issue Aug 12, 2020 · 17 comments
Labels
question Further information is requested

Comments

@MarZab
Copy link

MarZab commented Aug 12, 2020

Currently, ForkTsCheckerWebpackPlugin is enabled when TypeScript is enabled.

While building, the service is run for each build, breaking the build when enough endpoints are defined:

Starting type checking service...
Starting type checking service...
Starting type checking service...
(node:6910) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 exit listeners added to [process]. Use emitter.setMaxListeners() to increase limit

I would suggest a configuration option to not run ForkTsCheckerWebpackPlugin on build or to somehow run it before building.

@jayair
Copy link
Member

jayair commented Aug 17, 2020

Oh that's interesting. Does this error out the build?

@MarZab
Copy link
Author

MarZab commented Aug 17, 2020

Yes, but not before freezing up my computer :D

Up to 4-5 endpoints it works, it does take a long time.

@ashutoshkmr
Copy link
Contributor

I am also facing the same issue

@jayair
Copy link
Member

jayair commented Sep 7, 2020

@MarZab @ashutoshkmr Can you create a simple repo that I can test with?

@jayair jayair added the question Further information is requested label Sep 7, 2020
@MarZab
Copy link
Author

MarZab commented Sep 8, 2020

The issue shows up with package.individually = true.

With trivial examples it takes a few more endpoints than with larger codebase for the it to come up.

https://github.com/MarZab/serverless-bundle-typescript-timeout

% npm run sls package

Serverless: Bundling with Webpack...
Starting type checking service...
Starting type checking service...
Starting type checking service...
Starting type checking service...
Starting type checking service...
Starting type checking service...
Starting type checking service...
Starting type checking service...
Starting type checking service...
Starting type checking service...
(node:71290) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 exit listeners added to [process]. Use emitter.setMaxListeners() to increase limit
(Use `node --trace-warnings ...` to show where the warning was created)
^C

@jayair
Copy link
Member

jayair commented Sep 9, 2020

Thanks for the repo.

I looked into it. It seems like serverless-webpack has been trying to resolve this issue (serverless-heaven/serverless-webpack#299 (comment)) and they have a proposed fix (serverless-heaven/serverless-webpack#517) in their upcoming 5.4.0 release.

It serializes the compile process. I still see the Node warning about the memory leak. But the functions seem to get packaged.

I created a branch for you to test with:

$ npm install --save-dev AnomalyInnovations/serverless-bundle#issue-127-forktschecker

And enable the option in your serverless.yml using:

custom:
  bundle:
    serializedCompile: true

I don't think the solution is ideal. I'd prefer being able to set the concurrency instead. But give it a shot.

@MarZab
Copy link
Author

MarZab commented Sep 10, 2020

I tried on my project, and it did complete while also showing the memory leak.

But it took a lot longer so I did some testing. I added an option to disable forktschecker here.

Config Build Time System Load
tsForkTsChecker: false serializedCompile: false 69.41s 10
tsForkTsChecker: true serializedCompile: true 375.33s 21
tsForkTsChecker: true serializedCompile: false frooze 427
tsc --noEmit 20.25s 7

My solution for now is to not use serializedCompile and to disable tsForkTsChecker compile time.

@jayair
Copy link
Member

jayair commented Sep 10, 2020

Yeah the serializedCompile will take longer. This option isn't directly related to forktschecker but it's a problem that a lot of people that use the package.individually option have. From having a look at the serverless-webpack 5.4.0 release roadmap, it seems like an issue they are trying to tackle. I'm leaning towards waiting for them to take a crack at it.

Maybe for the time being hang on to your solution?

@Namstel
Copy link

Namstel commented Nov 20, 2020

We're also running into this issue, but so far the only issue we have is that it slows down deployment by a lot.

Deployment with tsForkTsChecker turned off is 19 seconds and deployment with it turned on is 49 seconds.

I'm looking forward to seeing @MarZab 's solution in serverless-bundle.

@jayair
Copy link
Member

jayair commented Nov 22, 2020

@Namstel So it's faster with ForkTsChecker turned off?

@Namstel
Copy link

Namstel commented Nov 24, 2020

@jayair Yes definitely.

@jayair
Copy link
Member

jayair commented Jan 3, 2021

We are hearing a ton of folks having memory related issues because of this plugin. Anybody want to take a crack at this and making ForkTsChecker an option instead?

@ashutoshkmr
Copy link
Contributor

Hey @jayair
I've created a PR to make ForkTsChecker an option

@ceoshikhar
Copy link

Hey @jayair
I've created a PR to make ForkTsChecker an option

@jayair Please have a look at the PR. I have been having a really bad time with this memory leak error. My deployments pipeline fail 9/10 times because it crashes the entire process and if I deploy it on my machine it freezes my computer. I hope this gets fixed soon.

@jayair
Copy link
Member

jayair commented Jan 7, 2021 via email

@jayair
Copy link
Member

jayair commented Jan 7, 2021

Hi all, we made this an option:

https://github.com/AnomalyInnovations/serverless-bundle/releases/tag/v4.2.0

Read more on the option here: https://github.com/AnomalyInnovations/serverless-bundle#forktscheckerwebpackplugin

Can you try it and let me know if it fixes your issues?

@ceoshikhar
Copy link

@jayair I am currently on version 3.0.0, will it break anything if I upgrade to 4.2.0 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

5 participants