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

Document which CLI flags are/aren't available from node module #3587

Closed
codewith-luke opened this issue Oct 17, 2017 · 12 comments · Fixed by #5357
Closed

Document which CLI flags are/aren't available from node module #3587

codewith-luke opened this issue Oct 17, 2017 · 12 comments · Fixed by #5357

Comments

@codewith-luke
Copy link

Hi there,

Been doing some digging into using lighthouse programmatically.
https://github.com/GoogleChrome/lighthouse/tree/04b685fa9f492039ba54d60bbfaa8345c85c64dd/docs
Looking into passing flags to generate JSON files I noticed that this only actually utilizes this flag in the lighthouse-cli.

So by passing an outputPath would as a result do nothing? This is more of a confirmation more than anything. As I know you get the result set on the response etc and could just create your own file using nodes file system. Im more just wanting to see if I am missing something in utilizing lighthouse to do this for me.

@codewith-luke codewith-luke changed the title Passing outputPath and output flags through custom integration Passing outputPath and output flags through implementation of lighthouse programmatically Oct 17, 2017
@mingsterism
Copy link

Hi, I noticed that there is no documentation on the format of flags if using lighthouse through nodejs.
For example: I've tried using outputPath: "./myfile.json" and outputpath: "./myfile.json" but none works.
Thanks

@patrickhulce
Copy link
Collaborator

Hey folks, thanks for raising this. You are correct. Output path is a flag that is only respected by the CLI and not when using Lighthouse programmatically under the assumption that if you're using Lighthouse from node you want to consume the results yourself in the object it returns rather than just dump to disk somewhere.

I'm converting this issue to better documenting this fact. 👍

@patrickhulce patrickhulce changed the title Passing outputPath and output flags through implementation of lighthouse programmatically Document which CLI flags are/aren't available from node module Oct 27, 2017
@nhodges
Copy link
Contributor

nhodges commented Nov 17, 2017

@patrickhulce, @factordog

Has the documentation been updated? Just ran into this while implementing the node module and subsequently discovered this issue.

@patrickhulce patrickhulce reopened this Nov 17, 2017
@patrickhulce
Copy link
Collaborator

No it has not, thanks for flagging this as being prematurely closed @nhodges and double thanks for the PR! :)

@paulirish
Copy link
Member

@factordog @mingsterism do you recall why you wanted to set outputpath? did you want html results also?

@codewith-luke
Copy link
Author

@paulirish Been a while since I have had to come back to this situation. But from what I recall yes. It was about passing in the command line flags and getting back similar results as you would there. In fact I dont even think it was just for the HTML but also the JSON (lighthouse --output json --output html).

However once it was bought to my attention that the data returned was all the raw data that we could use as we wish I could see why it wasn't technically necessary to be able to pass those types of flags.

@nothingismagick
Copy link

nothingismagick commented May 2, 2018

I posted first over at #4715 - but this is more appropriate I believe.

We are integrating lighthouse into the quasar-framework as the fourth and final component of our new testing mode, and I have been looking literally way too long (3 hours?) for how to get access to the opts.

It got to the point where I started tracking the way that functions were passing variables within lighthouse core, and then I just caved and decided that before I file an issue I should search for it, because with this many stars I cannot be the first to have this problem. Low and behold, no - this has been an issue for over 6 months... :|

Anyway, I have several recommendations to resolve this.

  1. Make it clear that it is possible to access the CLI options via config files (for the CLI or the NODE interface). Explicitly give an example of this in a prominent place, such as in the README.md in the root folder of this repo. [edit] Some settings are better integrated than others...
  2. Differentiate between settings, options and configurations. These are all so semantically similar, that I think the use of all three should be canonised with regard to how the Lighthouse project understands them and uses them. (If this has been done, please point me toward it!)
  3. Decide if the project wants to use .json or .js for the configuration files that hold options and settings. I have seen both. Does It matter? Tell us.
  4. Does one need an =on the command-line between the key and the value? I have seen both. Does it matter? Tell us.

@taytus
Copy link

taytus commented Feb 27, 2019

@factordog @mingsterism do you recall why you wanted to set outputpath? did you want html results also?

Hello Paul, I'm still struggling to define the outputPath, and yes, I would like to dump the HTML report too.

Thanks!

@patrickhulce
Copy link
Collaborator

@taytus output path is one of them that is CLI-only and has been thoroughly documented.

@taytus
Copy link

taytus commented Feb 27, 2019

Thank you @patrickhulce. You are right, I was just starting diving into lighthouse and honestly, I thought it was odd I couldn't easily define the output path for the reports.

I posted my hacky workaround here: #5269 (comment)

I appreciate your help.

@patrickhulce
Copy link
Collaborator

@taytus if that's all you're doing you should probably just be using the CLI, that's what it's made for, and also why there is an outputPath option there but not in node.

@taytus
Copy link

taytus commented Feb 27, 2019

@patrickhulce, for now, I will follow your advice and go with node. We need to generate different config files for different scenarios, hence the need to set up that inside the .js file.

Thank you again.

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

Successfully merging a pull request may close this issue.

8 participants