-
Notifications
You must be signed in to change notification settings - Fork 251
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
feat(package): restructure package internals #2714
Conversation
Update all package to direct TS output to dist directories in each package.
Reduce complexity by no longer compiling files in the root of the api package.
Is it ready to be checked @nicojs ? |
@kmdrGroch this is ready for review now. You might want to focus on the eslint and typescript config stuff, nearly all files have changes 🤷♀️ |
@@ -0,0 +1 @@ | |||
module.exports = require("./dist/src/check") |
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.
Should JS and .D.TS files be on github tho? 🤔
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.
Great question!
I would actually like to have it as a *.ts file, but that would mean we would need to compile those files in place (not to the dist
directory), because I want this import to work: import { File } from '@stryker-mutator/api/core'
and that can only be done with a file called "core.js" inside api (on node < 12.7).
When we drop support for node < 12.7 we can start using exports
and remove these root files altogether.
I don't want to make an exception for some files to be compiled in place, because that also means making an exception in our clean script and making the output files hidden in vscode config (i don't like hidden files 😢). This all adds complexity that I don't want.
Do you agree with this? In short: we should be able to remove these files once we can use exports
in package.json.
@@ -1,11 +0,0 @@ | |||
export { default as File } from './src/core/file'; |
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.
typescript files are removed? 🤔
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, see my previous remark.
@@ -1,7 +1,7 @@ | |||
import { expect } from 'chai'; | |||
import { deserialize, serialize } from 'surrial'; | |||
|
|||
import { File } from '../../../core'; | |||
import { File } from '../../../src/core'; |
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 don't quite like pathing to src from tests / packages
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.
Ah, you mean just import from '../../../core'
? Yes that would be possible here because of the new d.ts
files.
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.
sorry, that doesn't work. See my latest comment
@@ -2,13 +2,13 @@ | |||
"name": "@stryker-mutator/core", | |||
"version": "4.4.0", | |||
"description": "The extendable JavaScript mutation testing framework", | |||
"main": "src/index.js", | |||
"main": "dist/src/index.js", |
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.
dist/src/index? so is it dist or src ;)
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. So src
is compiled to dist/src
and test
is compiled to dist/test
. If you really want src
to be compiled to dist
we would need to add the tests inside the src
directory. I don't really mind this that much; we can go either way.
What do you think?
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 haven't noticed we have src and test in dist. If it is like this, it is ok i believe :)
Tho it should be consistent 🤔
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.
What would be consistent?
I've been thinking and having src
compile to dist
would also mean moving the typings
, src-generated
, and schema
directories src
directory. We can do that, but it would take some more effort.
public readonly proxy: Promisified<T>; | ||
|
||
private readonly worker: ChildProcess; | ||
private readonly worker: childProcess.ChildProcess; |
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 like this change, provides more information what it is, especially in fork
@@ -8,14 +8,14 @@ class State { | |||
} | |||
|
|||
public coverageAnalysis: CoverageAnalysis = 'off'; | |||
private mutantCoverageHandler: MutantCoverageHandler; | |||
private mutantCoverageHandler?: MutantCoverageHandler; |
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.
again optional? 🤔
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.
Yeah, the same reasoning as before. This is because I enabled --strictPropertyInitialization
.
@@ -1,5 +1,5 @@ | |||
import { expect } from 'chai'; | |||
import * as Mocha from 'mocha'; | |||
import Mocha from 'mocha'; |
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.
Mocha? not mocha?
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.
It's a constructor function (or class
) 🤷♂️
public options: StrykerOptions; | ||
public logger: sinon.SinonStubbedInstance<Logger>; | ||
public injector: Injector<PluginContext>; | ||
public pluginResolver!: sinon.SinonStubbedInstance<PluginResolver>; |
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.
!? are they possibly undefined?
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, this is because of --strictPropertyInitialization
again. But this time I used a !
(not null assertion) instead of a ?
, because I know for sure this can only theoretically be undefined and will always be defined in practice because I call reset
directly inside this file (and it's a singleton).
perf/tasks/install.ts
Outdated
import fs from 'fs'; | ||
import minimatch from 'minimatch';; | ||
import path from 'path' | ||
import execa from 'execa';; |
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.
what happened here? 😆
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.
Midnight hacking 😅
Will fix
perf/tasks/run-perf-tests.ts
Outdated
import * as execa from 'execa'; | ||
import fs from 'fs'; | ||
import path from 'path' | ||
import execa from 'execa';; |
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.
same here
Thanks for your great feedback @kmdrGroch . I've commented on each remark and fixed some issues. |
The only thing thats left is just making it green again :D |
import chai, { expect } from 'chai'; | ||
import { it } from 'mocha'; |
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 think thats an issue
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.
Importing it
from mocha is optional. Mocha will make sure it
is globally available. I've removed it since we're never importing it
.
@kmdrGroch I had to revert the imports in the api tests. import { TestStatus } from '../../../src/test-runner'; // -> this works
import { TestStatus } from '../../../../test-runner'; // -> this compiles, but at runtime won't resolve, because the root dir is one directory more up
import { TestStatus } from '../../../../../test-runner'; // -> this would resolve at runtime, but doesn't compile 🤷♂️ |
Good find with the snapshot file. Snapshot remapping broke somehow, I've implemented it with some clever sourcemap magic. |
If you want I can review it once more, but probably tomorrow since today I am busy. Or you could merge it and hope for the best 😅 |
Living on the edge 😉 If we something after the fact, we will open a new PR. |
--strict
mode`import path from 'path'),import * as path from 'path'
If you're using deep-imports from
@stryker-mutator/core
or friends, they will have to be updated. Note: as a general rule: don't rely on deep imports from Stryker, as they might break at any moment.