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

TypeScript tests are way too slow in CI #1359

Closed
cmnrd opened this issue Sep 7, 2022 · 5 comments · Fixed by #1426
Closed

TypeScript tests are way too slow in CI #1359

cmnrd opened this issue Sep 7, 2022 · 5 comments · Fixed by #1426
Labels
ci Continuous integration help wanted Extra attention is needed typescript Related to TypeScript target

Comments

@cmnrd
Copy link
Collaborator

cmnrd commented Sep 7, 2022

At the moment the TypeScript Test for MacOS and Windows run for more than 4 hours. This is way too long. Do we know why it takes so long (for Linux it is only one hour)? Is there a way to cut down the number of tests run? Or can we maybe split the TypeScript tests into multiple jobs that can run in parallel?

@cmnrd cmnrd added typescript Related to TypeScript target ci Continuous integration labels Sep 7, 2022
@lhstrh lhstrh added the help wanted Extra attention is needed label Sep 16, 2022
@lhstrh
Copy link
Member

lhstrh commented Sep 16, 2022

They shouldn't be so slow, but it hasn't been an issue to address it. Perhaps @byeong-gil has any ideas?

@byeonggiljun
Copy link
Collaborator

@lhstrh Actually, I have run the TypeScript test only in Linux. So I don't have any idea about this problem yet...
I'll try to examine what happens in the Windows TypeScript test.

@lhstrh
Copy link
Member

lhstrh commented Sep 16, 2022

One thing we could do is disable the tests on Windows and Mac, but that, of course, isn't really addressing the problem...

@petervdonovan
Copy link
Collaborator

The only suggestion I have ever put forward to fix this was to bundle the dependencies of the reactor-ts runtime into it. Everything that it would need would be stuffed into one big JS file, which we could minify if we want. A downside is that if the end user wants to use the same library as is used by the runtime, then they would have to import it again, and there would be code duplication in the generated JS. I almost implemented this already, actually, in #1322, but I gave up because I was inexperienced with the NPM/TS ecosystem, and just getting anything to work was a painful process for me.

I personally would be happy with considerably scaling back the tests on Windows and Mac, at least as a stopgap measure. Node is supposed be mostly platform-independent (right?), and although I remember addressing platform compatibility issues to get the TS target to work on Windows, they were pretty superficial bugs that would have been caught by a simple smoke test.

@petervdonovan
Copy link
Collaborator

petervdonovan commented Oct 11, 2022

By "superficial bugs," I mean things like using Bash commands in the scripts in package.json, not misbehaving JavaScript code. It seems like microtime, which we depend on, might be doing some low-level magic, but AFAIK we have not had issues with that dependency.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ci Continuous integration help wanted Extra attention is needed typescript Related to TypeScript target
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants