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

Add --telemetry argument and ensure running without telemetry is possible #287

Merged
merged 6 commits into from
Apr 27, 2020

Conversation

rajasegar
Copy link
Member

Fixes #282

@tylerturdenpants
Copy link
Collaborator

Let' get this bad boy over to github actions. 😉LGTM. Thank you

@tylerturdenpants
Copy link
Collaborator

Oh one thing, should we have tests for the new command line options? Just a thought.

@rajasegar
Copy link
Member Author

@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
@rajasegar
Copy link
Member Author

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

return !(KNOWN_HELPERS.includes(name) && config.helpers.includes(name));

The commit:
8e4fb8b#diff-0d3de8cb5f879d03639b6a16d0eddee0

@tomwayson
Copy link
Contributor

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);
Copy link
Contributor

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 || [].

Copy link
Member

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

Copy link
Member Author

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 Show resolved Hide resolved
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
Copy link
Member

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.

Copy link
Contributor

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?

Copy link
Member Author

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

Copy link
Member

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

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

Copy link
Contributor

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?

Copy link
Member Author

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

Copy link
Member

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

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)

Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Contributor

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

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
@rajasegar
Copy link
Member Author

Thanks @tomwayson @rwjblue for the review. Addressed the same in the latest commit.

@rajasegar rajasegar changed the title [BREAKING CHANGE]: disabling telemetry by default [BREAKING CHANGE]: making telemetry optional Apr 24, 2020
Copy link
Contributor

@tomwayson tomwayson left a 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!

@rwjblue rwjblue changed the title [BREAKING CHANGE]: making telemetry optional Add --telemetry argument and ensure running without telemetry is possible Apr 27, 2020
@rwjblue rwjblue merged commit 2912df0 into ember-codemods:master Apr 27, 2020
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.

Making Telemetry optional instead of default
4 participants