search

TypeStrong / fork-ts-checker-webpack-plugin

Webpack plugin that runs typescript type checker on a separate process.
MIT License
1.95k stars 240 forks source link

Limit service concurrency #441

Closed shadrech closed 3 years ago

shadrech commented 4 years ago

Feature motivation

I'm running this plugin in a serverless framework project. Now that I have multiple lambda functions this plugin is now taking up quite a lot of memory

Feature description

Is there a way to limit the amount of concurrent services it runs? So maybe an option saying process only 10 services at the same time, the others can wait

piotr-oles commented 4 years ago

Related: #424

shadrech commented 4 years ago

@piotr-oles Thanks for swift reply! It would be nice if this was a feature added to the plugin 🙈 As serverless framework and typescript become more popular I can see a lot of people using this plugin and coming across this issue. But I've just settled for the fork-ts-checker-webpack-plugin-limiter plugin 👍🏾

stale[bot] commented 4 years ago

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

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

TheNickmaster21 commented 3 years ago

I have not had luck using the fork-ts-checker-webpack-plugin-limiter. We have a severless repository containing 35 lambdas that are packaged and built separately. When running with this plugin, our build times are shorter but we have been getting crashes during build because of the memory and processing requirements of running 35 instances of this plugin at one time. Is there still not a clean way to limit the concurrency? Even when limiting parallelism in our webpack config, we end up with 35 node instances of this plugin running at once.

piotr-oles commented 3 years ago

@TheNickmaster21 fork-ts-checker-webpack-plugin-limiter didn't work? I would not like to add this functionality to the plugin unless there is a higher demand for it. Adding new options to the API will increase complexity and maintenance costs :/

TheNickmaster21 commented 3 years ago

It did not help for us. I tried the custom solution and the actual published npm package and neither seemed to work. We have actually switched to just doing a tsc --noEmit at the root of our project as a prebuild step instead of using this plugin. It takes only 30ish second and catches the same issues.

vicary commented 3 years ago

@TheNickmaster21 I have a comprehensive explanation of my config on serverless and how things are stitched together, you may want to take a look at https://github.com/FidelLimited/serverless-plugin-optimize/issues/72#issuecomment-717717844

piotr-oles commented 3 years ago

:tada: This issue has been resolved in version 6.1.0 :tada:

The release is available on:

Your semantic-release bot :package::rocket: