-
-
Notifications
You must be signed in to change notification settings - Fork 73
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
Update workerpool #203
Update workerpool #203
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tests aren’t running (GH Actions won’t run when added in a fork). Let’s do the CI changes in a separate PR, all by themselves. Then we can rebase this against those changes and confirm things actually pass.
pool = workerpool.pool(path.join(__dirname, 'worker.js'), { maxWorkers: JOBS }); | ||
pool = workerpool.pool(path.join(__dirname, 'worker.js'), { | ||
maxWorkers: JOBS, | ||
workerType: 'process' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why force process
here? If thread is available I don’t see why we’d want to force process.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well tests fail if we don't 😂 I don't really understand why, I was trying to do the minimum effort to get this passing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thread is the preferred approach here... fallback to process only when absolutely needed.
@@ -44,7 +44,7 @@ | |||
"heimdalljs-logger": "^0.1.7", | |||
"json-stable-stringify": "^1.0.0", | |||
"rsvp": "^4.8.2", | |||
"workerpool": "^2.3.0" | |||
"workerpool": "^6.1.4" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is breaking in a way that we typically do not do... 🤔
Specifically, this is changing an old major to drop support for a Node major version with the expectation of releasing without a breaking change indication. This is likely to cause exactly the kind of breakage you are trying to fix (introduced CI failures).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I wasn't intending to drop support for any node version 🤔 the idea was that the tests should still check the correct Node version. I guess technically because workerpool aren't testing against our supported Node versions they could break older ones at any time, is that what you mean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess technically because workerpool aren't testing against our supported Node versions they could break older ones at any time, is that what you mean?
Yes, exactly. They could update to (for example) async/await syntax, which would be breaking for Node 8 users (which ember-cli-babel@6 still supports).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, the right fix (as I mentioned in #203 (review)) is to disable parallelizing when running on Node 16. It is the least invasive change, and has the least likely hood of breaking folks.
strategy: | ||
matrix: | ||
os: ['ubuntu', 'windows', 'macOS'] | ||
node: ['10', '12', '14'] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn’t test node 16 (which is theoretically the point?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes you're right I should have added that. I'll split the CI stuff and then add 16 in this PR when it's rebased 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we think this is critical to fix, versus just saying Node 16 is the end of the line for folks that haven’t updated to ember-cli-babel@7 (which is very old at this point), I’d rather just drop support for parallelizing when running on Node 16 (and not change the workerpool dependency).
That would be done by making this return false
when on Node 16:
broccoli-babel-transpiler/lib/parallel-api.js
Line 104 in fa52187
isParallelizable: isSerializable(options), |
What exactly was the fix? It may be practical to backport to an older workerpool. |
So this was the change that fixed it in Node 16: https://github.com/josdejong/workerpool/pull/230/files I had a quick look and it does seem like we could backport it because the same code does exist https://github.com/josdejong/workerpool/blob/v2.3.3/lib/WorkerHandler.js#L174 but I'm not entirely sure which part of it was failing 🤔 we couldn't use the same code change. I was going to just try what @rwjblue was suggesting next i.e. remove the call to workerpool for any Node version > 14 |
@mansona if you can backport, I can release |
@stefanpenner it looks like the backport actually works as-is 😱 I have a branch that I've tested in Node 6 and Node 16 https://github.com/mansona/workerpool/tree/fix-node-16 Can you create a v2 release branch so that I can target it with a PR? |
@mansona @stefanpenner @rwjblue [email protected] patch version was released. Does it mean we need to proceed with this PR? I would assume, we only need to migrate Travis -> GH Actions.
|
@mansona @stefanpenner ping, any help needed here? |
@mansona @stefanpenner @rwjblue sorry for pinging you again - is there a way to move this PR forward? |
Closing as the fix (and a patch release) landed in the older version of workerpool |
Over the last week or so, I have been tracking down an issue that prevented some Ember apps from working/building in Node 16. After a conversation with @Turbo87 on Discord we thought that we should update the workerpool sub-dependency of ember-cli-babel@6 because that was causing the underlying issue.
I have successfully tested the change in this PR by updating the broccoli-babel-transpiler dependency to target this branch in a PR/branch in ember-cli-babel and then subsequently doing some manual(ish) yarn.lock manipulation to force an application to use that ember-cli-babel branch. You can check out the changes in this PR: ember-fastboot/ember-cli-fastboot#834 and the fact that the tests are passing should be a good indication that the experiment has worked 🎉
This PR does the following:
workerType
because the default changed (and I set it to what it would have been)If we agree with my approach then we would need to cut a new v6 patch (or minor?) release after this is merged.
Let me know if you have any questions 👍