Closed lelandrichardson closed 7 years ago
The config structure is now changed so that it requires a targets array of "target" objects.
Would it make sense to use an object instead of an array here? I feel like that would be more straightforward.
module.exports = {
targets: {
firefox: firefoxTarget({
viewports: { ... },
}),
reactNativeIOS: reactNativeTarget(),
}
}
Oh, but the name
is probably useful down the line when generating diff pages for multiple targets? So having it attached to the target itself makes things easier.
Also since the method creating the target is expected to return an instance, maybe it would be better to have targets as classes?
const FirefoxTarget = require('happo-target-firefox');
module.exports = {
targets: [
new FirefoxTarget({
viewports: { ... },
}),
],
};
@lencioni @trotzig I moved some things around a bit more. The project now runs and works as far as i can tell. It looks like right now it's consistently marking the 2nd example in the example project as having a diff though. is that expected?
I ended up moving the example project into the packages directory as it makes it easier with all of the automatic symlinking that lerna does for us.
The way I had set up the config
in happo-core
was causing a bunch of circular dependencies because the config is a runtime JS file which would probably require a happo library (like happo-target-firefox
) which would in turn depend on config
from happo-core
.
In order to fix the circular dependencies, I made the config
object just a container for an injectable singleton config.
Also since the method creating the target is expected to return an instance, maybe it would be better to have targets as classes?
Good call. Updated to reflect this.
Would it make sense to use an object instead of an array here? I feel like that would be more straightforward.
I think having the target have a "default" name works fine, and then allows users to define more than one of the same target if they like. The expense is an array lookup in the CLI, but i don't think that matters much.
The project now runs and works as far as i can tell. It looks like right now it's consistently marking the 2nd example in the example project as having a diff though. is that expected?
Yep, it has a Math.random()
in its rendering.
I'm trying this out locally, and so far I haven't run into any issues. 💯
Just to make sure I understand things correctly, this is what I did to try things out:
$(npm bin)/lerna bootstrap
packages/happo-example-project
and ran happo run firefox
packages/happo-target-firefox
happo run firefox
in the example projectnpm run babel -- --watch
from within happo-target-firefox
happo run firefox
Great work!
@trotzig yeah, that should do it. I tried to set things up so we didn't need to cd
into any directories. From the root directory you should be able to:
./example <command>
should run happo <command>
in the example projectnpm run watch
should watch all of the projects at the same timelerna run build
should build all of the projects at the same timenpm test
should run the tests on the whole projectPerhaps i should make npm run build
work from the root so that those commands are symmetric
@trotzig @lencioni made npm
commands for watch and build so people don't necessarily need to know to use lerna now
Will start working on tweaking the readme
@lencioni @trotzig I added a happo-uploader-s3
package, and updated some of the READMEs. PTAL!
Note: i'm thinking about adding a gitbook documentation site in a followup PR, as happo will begin to have a larger surface area with more targets/uploaders/ci etc.
@lencioni agreed. I think w/ tests passing and no glaring "we should not do {x}" or "we should fix {y}", we should merge and maybe hold off on publishing for a little bit while we continue to smoke test. What do you think?
@lelandrichardson that sounds good to me.
to: @lencioni @trotzig
Overall, this PR breaks the project into 5 packages:
happo
: this is essentially the CLI (could also be renamed ashappo-cli
potentially)happo-core
: this is a core module (and has no other happo dependencies) and contains some of the core logic functions for happo like image comparison, and also has the mainconfig
module.happo-viewer
: this is the website for viewing diffshappo-target-firefox
: this is all of the logic needed to run the current firefox "target".happo-uploader-s3
: this is the uploader plugin that works with s3happo-example-project
: example projectThe config structure is now changed so that it requires a
targets
array of "target" objects. A target option has the following shape:The CLI commands that change as a result of this PR are:
runs happo with the passed in target name. If target is omitted, all targets run and are merged into a single result
runs
debug
on the passed target name.