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

feat(package): restructure package internals #2714

Merged
merged 23 commits into from Jan 27, 2021

Conversation

nicojs
Copy link
Member

@nicojs nicojs commented Jan 25, 2021

  • Redirect typescript output to "dist" directories
  • No longer compile "api" package root ts files (reduce complexity)
  • Enable typescript --strict mode
  • Fix 2 (small) bugs that resulted from uninitialized properties
  • Use default import syntax for commonjs modules instead of wildcard import syntax (eg. import * as path from 'path' `import path from 'path'),
  • Use named exports instead of a mix of default exports and named exports everywhere.
  • Force named exports using an eslint rule.

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.

- import { default as HtmlReporter } from '@stryker-mutator/core/src/reporters/html/html-reporter';
+ import { HtmlReporter } from '@stryker-mutator/core/dist/src/reporters/html/html-reporter';

@nicojs nicojs changed the title refactor(package): redirect compile output to dist directory feat(package): redirect compile output to dist directory Jan 25, 2021
@nicojs nicojs changed the title feat(package): redirect compile output to dist directory feat(package): restructure package internals Jan 27, 2021
@bartekleon
Copy link
Member

Is it ready to be checked @nicojs ?

@nicojs
Copy link
Member Author

nicojs commented Jan 27, 2021

@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")
Copy link
Member

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? 🤔

Copy link
Member Author

@nicojs nicojs Jan 27, 2021

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';
Copy link
Member

Choose a reason for hiding this comment

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

typescript files are removed? 🤔

Copy link
Member Author

@nicojs nicojs Jan 27, 2021

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';
Copy link
Member

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

Copy link
Member Author

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.

Copy link
Member Author

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",
Copy link
Member

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 ;)

Copy link
Member Author

@nicojs nicojs Jan 27, 2021

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?

Copy link
Member

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 🤔

Copy link
Member Author

@nicojs nicojs Jan 27, 2021

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;
Copy link
Member

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;
Copy link
Member

Choose a reason for hiding this comment

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

again optional? 🤔

Copy link
Member Author

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';
Copy link
Member

Choose a reason for hiding this comment

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

Mocha? not mocha?

Copy link
Member Author

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>;
Copy link
Member

Choose a reason for hiding this comment

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

!? are they possibly undefined?

Copy link
Member Author

@nicojs nicojs Jan 27, 2021

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).

import fs from 'fs';
import minimatch from 'minimatch';;
import path from 'path'
import execa from 'execa';;
Copy link
Member

Choose a reason for hiding this comment

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

what happened here? 😆

Copy link
Member Author

Choose a reason for hiding this comment

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

Midnight hacking 😅

Will fix

import * as execa from 'execa';
import fs from 'fs';
import path from 'path'
import execa from 'execa';;
Copy link
Member

Choose a reason for hiding this comment

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

same here

@nicojs
Copy link
Member Author

nicojs commented Jan 27, 2021

Thanks for your great feedback @kmdrGroch . I've commented on each remark and fixed some issues.

@bartekleon
Copy link
Member

The only thing thats left is just making it green again :D

import chai, { expect } from 'chai';
import { it } from 'mocha';
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 thats an issue

Copy link
Member Author

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.

@nicojs
Copy link
Member Author

nicojs commented Jan 27, 2021

@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 🤷‍♂️

@nicojs
Copy link
Member Author

nicojs commented Jan 27, 2021

Good find with the snapshot file. Snapshot remapping broke somehow, I've implemented it with some clever sourcemap magic.

@bartekleon
Copy link
Member

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 😅

@nicojs nicojs merged commit e1711d2 into master Jan 27, 2021
@nicojs nicojs deleted the refactor/typescript-projects branch January 27, 2021 16:29
@nicojs
Copy link
Member Author

nicojs commented Jan 27, 2021

Living on the edge 😉

If we something after the fact, we will open a new PR.

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.

None yet

2 participants