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

core(tracehouse): move files to core/lib/tracehouse/ #8956

Merged
merged 2 commits into from
Jun 5, 2019

Conversation

patrickhulce
Copy link
Collaborator

Summary
https://github.com/aslushnikov/tracium is basically a port of our files with a few things stripped out that we're encouraging external folks to use when trying to make sense of a trace. Keeping them in sync is going to be a nightmare unless we can publish from the source of truth. This is step 1 towards that goal.

  1. (This PR) Move the required files to a lib/tracium directory
  2. (Followup) Eliminate any dependencies from lib/tracium to the rest of LH
  3. (Followup) Port back the patches in https://github.com/aslushnikov/tracium.
  4. Retire https://github.com/aslushnikov/tracium / decide our monorepo strategy / do something to make external consumption and internal maintenance of tracium easier
  5. Continue to make ongoing generic improvements as necessary

cc @aslushnikov

IMPORTANT FOR MERGE Before merging we want to keep at least two commits separate to preserve history, all the file moves are in core(tracium): move files to lib/tracium/ commit which should allow us not to lose blame history, etc

@aslushnikov
Copy link

Retire https://github.com/aslushnikov/tracium / decide our monorepo strategy / do something to make external consumption and internal maintenance of tracium easier

@patrickhulce Yes! If tracium lives in Lighthouse repo (which is optimal imo) and publishes to tracium's npm, than we can just deprecate and archive the aslushnikov/tracium.

Very happy this is happening! 🎉

@paulirish
Copy link
Member

offline we discussed naming this tracehouse instead.

@patrickhulce patrickhulce changed the title core(tracium): move files to core/lib/tracium/ core(tracehouse): move files to core/lib/tracehouse/ May 20, 2019
Copy link
Member

@paulirish paulirish left a comment

Choose a reason for hiding this comment

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

@patrickhulce wanna rebase into your 2 separate commits for landing?

Copy link
Member

@brendankenny brendankenny left a comment

Choose a reason for hiding this comment

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

I'm really not a fan of having 2x of a bunch of file names in our repo, where one file is just pointing at the other, and this trend seems like it's only going to continue as we want to expose more things for external use.

I don't have a great suggestion besides real some real refactors for these files, though. Any ideas?

@@ -7,7 +7,7 @@

const Audit = require('./audit');
const NetworkRequest = require('../lib/network-request');
const {taskGroups} = require('../lib/task-groups');
const {taskGroups} = require('../lib/tracehouse/task-groups');
Copy link
Member

Choose a reason for hiding this comment

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

.js

@@ -11,7 +11,7 @@
'use strict';

const Audit = require('./audit');
const {taskGroups} = require('../lib/task-groups');
const {taskGroups} = require('../lib/tracehouse/task-groups');
Copy link
Member

Choose a reason for hiding this comment

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

.js :)

lighthouse-core/computed/trace-of-tab.js Show resolved Hide resolved
@patrickhulce
Copy link
Collaborator Author

Any ideas?

Monorepo where we actually depend on our own @lighthouzzzzzzz/core packages :)

@brendankenny
Copy link
Member

Monorepo where we actually depend on our own @lighthouzzzzzzz/core packages :)

the files would still be named the same without changes to either the lib/ or computed artifact files themselves, though?

@patrickhulce
Copy link
Collaborator Author

the files would still be named the same without changes to either the lib/ or computed artifact files themselves, though?

Oh, I see what you were saying now. Why don't we start naming our computed *-computed? this has been a problem in metrics for a long time and it's definitely annoying :)

@patrickhulce
Copy link
Collaborator Author

What's the final naming verdict?

Twitter poll time? 😈

@paulirish
Copy link
Member

brendan voiced a few more things:

  • not great that we end up with a computed/trace-of-tab that's nearly empty.
  • we got 3 main-thread-tasks.js now.
  • between main-thread-tasks, tracing-processor and trace-of-tab, surely we can kill off one of those.

@paulirish
Copy link
Member

What's the final naming verdict?

IMO tracehouse naming seems fine.

Why don't we start naming our computed *-computed?

agree. i'd love this. (separate PR, natch)

not great that we end up with a computed/trace-of-tab that's nearly empty.

aye. feels like a codesmell. dunno what we can do about it without adding too much magic.

we got 3 main-thread-tasks.js now.

audits could be called 'long-tasks' instead, but perhaps too late for that? the -computed fix would then disambiguate between the others..

between main-thread-tasks, tracing-processor and trace-of-tab, surely we can kill off one of those.

ayup. i think patrick was waiting to do the move first, but that seems rather tempting.

@patrickhulce
Copy link
Collaborator Author

not great that we end up with a computed/trace-of-tab that's nearly empty.

I'm not quite as concerned about this thing. One's the meat and the other is the adaptation of our meat to the ultra-LH-specific "computed artifact" concept which as long as we have generic library type things is relatively unavoidable. If tracehouse were it's own package on NPM we require'd in I don't think we'd be that worried about having a lightweight -computed wrapper.

audits could be called 'long-tasks' instead, but perhaps too late for that? the -computed fix would then disambiguate between the others..

The obvious step to me here is to parallel -computed and rename all our audits *-audit without changing their ids :)

Maybe I'm misunderstanding the primary concern here, but it sounds like these are all problems because the files have the same name?

i think patrick was waiting to do the move first, but that seems rather tempting.

Indeed I was, my plan for killing one of them is going to be controversial enough to warrant its own PR for discussion 😈

@patrickhulce
Copy link
Collaborator Author

@brendankenny what do you need to see from me to get this merged? :)

(if all looks good I will go ahead and re-rebase to have just the two commits)

Copy link
Member

@brendankenny brendankenny left a comment

Choose a reason for hiding this comment

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

not great that we end up with a computed/trace-of-tab that's nearly empty.

I'm not quite as concerned about this thing. One's the meat and the other is the adaptation of our meat to the ultra-LH-specific "computed artifact" concept which as long as we have generic library type things is relatively unavoidable. If tracehouse were its own package on NPM we require'd in I don't think we'd be that worried about having a lightweight -computed wrapper.

But this repo is where the files live, and if you want to edit them you just want to edit them, not step through several levels of indirection, all with the same file name, because we love our directory names.

It's a definite architecture smell.

-computed

Let's just start calling them what they really are and add -factory and tracehouse-impl (all for a single concrete implementation!) while we're at it 😢

if all looks good I will go ahead and re-rebase to have just the two commits

The lib case is huge, so let's go for it. I'm sure @paulirish checked the unit tests look good after the move, so I'll defer to his earlier LGTM on that.

@patrickhulce
Copy link
Collaborator Author

It's a definite architecture smell.

Ooooooooooh if we're just making commentary on the fact that it's not ideal that our repo is organized this way, then you know I wholeheartedly agree. But you already know my thoughts on this so no need for me to get the boxing gloves out 😉

@patrickhulce patrickhulce merged commit 1af2edd into master Jun 5, 2019
@patrickhulce patrickhulce deleted the tracium_prep branch June 5, 2019 02:53
@aslushnikov
Copy link

yay!! 🎉

What are the next steps?

@patrickhulce
Copy link
Collaborator Author

patrickhulce commented Jun 5, 2019

@aslushnikov here's the roadmap, probably 2 PRs away from matching current tracium :)

  1. Eliminate any dependencies from lib/tracehouse to the rest of LH
  2. Port back the patches in https://github.com/aslushnikov/tracium.
  3. Retire https://github.com/aslushnikov/tracium / decide our monorepo strategy / do something to make external consumption and internal maintenance of tracium easier
  4. Continue to make ongoing generic improvements as necessary

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants