-
Notifications
You must be signed in to change notification settings - Fork 32
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
Add --telemetry
argument and ensure running without telemetry is possible
#287
Conversation
Let' get this bad boy over to github actions. 😉LGTM. Thank you |
Oh one thing, should we have tests for the new command line options? Just a thought. |
@tylerturdenpants Yes, definitely I will add tests for non-telemetry use case |
1. Update snapshot for no telemetry test 2. Add no telemetry test to CI 3. Tweaked transform to work without telemetry
@tylerturdenpants @Turbo87 @rwjblue Just a heads up, I have changed the logic here to make the tests passing, seem to have some doubts why it was working previously with telemetry and suddenly failing to work without telemetry.
The commit: 8e4fb8b#diff-0d3de8cb5f879d03639b6a16d0eddee0 |
This would fix #217 as well, right? If so, I'm a big fan. |
@@ -317,7 +317,7 @@ function shouldIgnoreMustacheStatement(fullName, config, invokableData) { | |||
let strName = `${name}`; // coerce boolean and number to string | |||
return (isHelper || !isComponent) && !strName.includes('.'); | |||
} else { | |||
return !(KNOWN_HELPERS.includes(name) && config.helpers.includes(name)); | |||
return KNOWN_HELPERS.includes(name) && config.helpers.includes(name); |
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.
seem to have some doubts why it was working previously with telemetry and suddenly failing to work without telemetry.
I'm guessing that the tests haven't exercised this } else {
block for a while?
I do think the previous logic was wrong, but I'm not sure about your change. Based on let isHelper = mergedHelpers.includes(name) || config.helpers.includes(name);
from above, I would expect return KNOWN_HELPERS.includes(name) || config.helpers.includes(name);
I'm also wondering if there's additional logic inside the if (isTelemetryData) {
block that needs to be captured like whether or not it's a component and whether or not the name includes a .
.
Take this w/ a grain of salt b/c I haven't looked at the code outside of this fn, but it almost seems to me that you could remove isTelemetryData
the if/else
statement entirely and just execute what's in if
block b/c of helpers || []
and components || []
.
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.
Agree, I think this should probably be an ||
. 🤔
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.
Agreed, will change that
README.md
Outdated
@@ -23,14 +23,25 @@ It does not make a copy. Make sure your code is checked into a source control | |||
repository like Git and that you have no outstanding changes to commit before | |||
running this tool. | |||
|
|||
```sh | |||
$ cd my-ember-app-or-addon | |||
$ npx ember-angle-brackets-codemod ./path/of/files/ or ./some**/*glob.hbs |
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.
We should ask for --no-telemetry
to explicitly opt-out of telemetry gathering.
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.
That makes sense given that you want telemetry to be the default use case.
However, personally I like the current choice to have --telemetry=
replace --url=
. To me if you don't provide --telemetry=
, then --no-telemetry
is not needed unless you wanted to use a default URL for telemetry - is that what you are suggesting?
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 agree with @tomwayson, also having too many options/flags, for one thing, seems to bring in extra complexity
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.
When using yargs
you get --no-telemetry
"for free" when you configure --telemetry
to mean something. I think it is perfectly fine for the implementation to not require --telemetry
or --no-telemetry
(e.g. assume --no-telemetry
if there is no --telemetry
value provided) but our docs should explicitly pass the argument.
bin/cli.js
Outdated
@@ -2,8 +2,12 @@ | |||
'use strict'; | |||
const { gatherTelemetryForUrl, analyzeEmberObject } = require('ember-codemods-telemetry-helpers'); | |||
|
|||
const argv = require('yargs').argv; |
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 probably configure more parsing so we can give nicer error messages when the correct patterns aren't setup, also can emit --version
and --help
output "for free".
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.
is that w/in the scope of this PR though?
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 @tomwayson, the yargs parsing was brought as part of this PR, I will make the corrections accordingly
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.
Ya, I'm fine if we punt the --help
/ --version
bits to a different PR, but this PR should definitely define the specific arguments we do expect (e.g. --telemetry
, and the positional values for the globs).
"broccoli-asset-rev": "^3.0.0", | ||
"ember-ajax": "^5.0.0", | ||
"ember-bootstrap": "^2.8.1", | ||
"ember-cli": "~3.10.1", |
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.
Lets use a more modern ember-cli and app blueprint (either 3.16 or 3.18)
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.
would those have any culry invocations to convert?
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, ideally the modern version shouldn't have any curly invocations, @rwjblue do you still want to change that.
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.
Ya, I'd still prefer to use a new ember-cli. The templates that you check in aren't part of the app blueprint anyways so they would still have curlies or whatever you put in them.
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 it would be a good idea if the checked in app used a "mixed" layout, i.e. a classic app w/ at least a couple of pods artifacts to test. Like maybe a pods route that invokes a pods component?
That way the tests will verify that #217 is resolved.
I'd be glad to help w/ this. Maybe @rajasegar if you check in a classic 3.16/3.18 app w/ the tests working I can pull and generate the pods artifacts and push a commit w/ the updated fixture and tests?
@@ -317,7 +317,7 @@ function shouldIgnoreMustacheStatement(fullName, config, invokableData) { | |||
let strName = `${name}`; // coerce boolean and number to string | |||
return (isHelper || !isComponent) && !strName.includes('.'); | |||
} else { | |||
return !(KNOWN_HELPERS.includes(name) && config.helpers.includes(name)); | |||
return KNOWN_HELPERS.includes(name) && config.helpers.includes(name); |
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.
Agree, I think this should probably be an ||
. 🤔
1. Introduced more processing with yargs 2. Changed readme to show telemetry option as default 3. Tweak the transform logic for shouldIgnoreMustache
Thanks @tomwayson @rwjblue for the review. Addressed the same in the latest commit. |
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.
This LGTM! Thanks @rajasegar!
--telemetry
argument and ensure running without telemetry is possible
Fixes #282