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

Custom workerfarm, BI-Directional IPC #1105

Merged
merged 49 commits into from
Apr 15, 2018
Merged

Custom workerfarm, BI-Directional IPC #1105

merged 49 commits into from
Apr 15, 2018

Conversation

DeMoorJasper
Copy link
Member

@DeMoorJasper DeMoorJasper commented Mar 30, 2018

@DeMoorJasper
Copy link
Member Author

DeMoorJasper commented Mar 31, 2018

Tests pass locally on mac, windows, ubuntu server (with 500mb of ram and 4 cores).
The tests that fail on travis also fail in master branch (from time to time).
Everything should work, feel free to test

@davidnagli
Copy link
Contributor

So tests pass on Node 9, but when I tried it on Node 6 I got them to fail.

@DeMoorJasper
Copy link
Member Author

All tests that pass in master should pass in here now (node 8 & 6) + some that don't pass in master.
Tests have been added to make sure the workerfarm is reliable.

@@ -13,7 +13,10 @@ async function localRequire(name, path, triedInstall = false) {
resolved = resolve.sync(name, {basedir});
} catch (e) {
if (e.code === 'MODULE_NOT_FOUND' && !triedInstall) {
await install([name], path);
await worker.addCall({
location: './utils/installPackage.js',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems slightly strange that these locations are relative to the worker, not the current file like other require calls. Maybe it might be more readable if we resolved it here: location: require.resolve('./installPackage')

package.json Outdated
@@ -73,6 +72,8 @@
"coffeescript": "^2.0.3",
"cross-env": "^5.1.1",
"eslint": "^4.13.0",
"glsl-token-assignments": "^2.0.2",
"glsl-token-properties": "^1.0.1",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think these are just missing from the yarn.lock for some reason. They are already deps of glslify-bundle I think.

@@ -11,6 +11,8 @@ class GLSLAsset extends Asset {
}

async parse() {
await localRequire('glsl-token-properties', this.name);
await localRequire('glsl-token-assignments', this.name);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment as above, these should already get installed as part of glslify-bundle

@@ -0,0 +1,45 @@
require('v8-compile-cache');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

move this file out of the folder since it is parcel specific

@reflog
Copy link

reflog commented Apr 15, 2018

really looking forward to a merge of this PR. parcel is hanging on Windows quite often, so this is a godsend!

forcedKillTime: 100,
warmWorkers: true,
useLocalWorker: true,
workerPath: require.resolve('../worker')
Copy link
Member Author

@DeMoorJasper DeMoorJasper Apr 15, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will fail in Node 6. Because babel-register runs out of src instead of lib. Not sure why transpiling doesn't apply on workers though.
I've tried this before writing the pretty hacky way of resolving it

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah right. babel-register doesn't run inside the workers.

@codecov-io
Copy link

codecov-io commented Apr 15, 2018

Codecov Report

Merging #1105 into master will decrease coverage by 0.04%.
The diff coverage is 70.28%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1105      +/-   ##
==========================================
- Coverage   88.36%   88.32%   -0.05%     
==========================================
  Files          74       77       +3     
  Lines        3695     4384     +689     
==========================================
+ Hits         3265     3872     +607     
- Misses        430      512      +82
Impacted Files Coverage Δ
src/Logger.js 96.84% <100%> (-1.04%) ⬇️
src/worker.js 100% <100%> (+10.52%) ⬆️
src/Bundler.js 89.37% <100%> (ø) ⬆️
src/utils/localRequire.js 90.32% <50%> (-3.02%) ⬇️
src/workerfarm/WorkerFarm.js 46.93% <55.07%> (ø)
src/workerfarm/Worker.js 68.75% <68.75%> (ø)
src/workerfarm/errorUtils.js 82.35% <80%> (ø)
src/workerfarm/child.js 95.08% <94.64%> (ø)
src/assets/WebManifestAsset.js 59.18% <0%> (-19.39%) ⬇️
src/assets/JSONAsset.js 84.61% <0%> (-7.7%) ⬇️
... and 34 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 25a054f...5a63658. Read the comment docs.

@devongovett devongovett merged commit 69625e0 into master Apr 15, 2018
@devongovett devongovett deleted the custom-workerfarm branch April 15, 2018 17:53
@reflog
Copy link

reflog commented Apr 16, 2018

Thank you!

@tinchoz49
Copy link

tinchoz49 commented Apr 24, 2018

Hi everyone! how are you?

Is there any breaking change in this PR about how we can define a custom asset?

I'm using parcel-plugin-typescript and with the version 1.7.1 of parcel I'm getting this error: fathyb/parcel-plugin-typescript#36

But it seems that everything is ok with the plugin and it was working fine until the version 1.7.0 of parcel.

@DeMoorJasper
Copy link
Member Author

DeMoorJasper commented Apr 26, 2018

@tinchoz49 Yes, this PR has a stricter error handling than the previous implementation, therefore unknown ipc communication results into throwing an error.
This should be fixed if #1235 lands, as plugins can inject functions into the parcel workers

It would also improve performance of parcel-plugin-ts as it doesn't need to start up their own workers

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

Successfully merging this pull request may close these issues.

6 participants