-
Notifications
You must be signed in to change notification settings - Fork 795
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
feat(telemetry) adding yarn 1 support, sanitizing data pre-flight #3082
Conversation
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 took a first pass on this, but didn't get around to testing it going much deeper than the surface level. LMK what you think
src/cli/telemetry/telemetry.ts
Outdated
packages = await npmPackages(sys, ionicPackages); | ||
} else if (isUsingYarn(sys)) { | ||
packages = await yarnPackages(sys, ionicPackages); | ||
} else { |
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.
Doesn't isUsingYarn
always return a boolean? I'm not sure I see the scenario where this else
block is entered (since we test both isUsingYarn
in the else if
condition and it's negation in the if
condition clause)
In fact, I think this could be refactored as such
// NOTE to not be committed: I pulled this out to keep our `try` block tiny
const isUsingYarn = isUsingYarn(sys);
try {
packages = isUsingYarn ? await yarnPackages(sys, ionicPackages) : await npmPackages(sys, ionicPackages);
} catch (e) {
packages = ionicPackages.map(([k, v]) => `${k}@${v.replace('^', '')}`);
}
@@ -79,6 +79,8 @@ | |||
"@types/sizzle": "^2.3.2", | |||
"@types/webpack": "^4.41.26", | |||
"@types/ws": "^7.4.0", | |||
"@types/yarnpkg__lockfile": "^1.1.5", | |||
"@yarnpkg/lockfile": "^1.1.0", |
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.
Can you add @yarnpkg/lockfile
to
Line 12 in 66d0476
'@rollup/plugin-node-resolve', |
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.
As a dev dependency, how is this getting rolled up and put in the final compiler output?
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.
It's a part of the compiler process, since anything within the node sys gets bundled up and shipped. Similar to how we bundle TypeScript or Rollup.
src/cli/telemetry/telemetry.ts
Outdated
*/ | ||
async function yarnPackages(sys: d.CompilerSystem, ionicPackages: [string, string][]) { | ||
const appRootDir = sys.getCurrentDirectory(); | ||
const yarnLock = sys.readFileSync(appRootDir + '/yarn.lock'); |
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 use path.join
(or the sys equivalent) here, to make the path delimiter OS-agonstic
*/ | ||
async function npmPackages(sys: d.CompilerSystem, ionicPackages: [string, string][]) { | ||
const appRootDir = sys.getCurrentDirectory(); | ||
const packageLockJson: any = await tryFn(readJson, sys, sys.resolvePath(appRootDir + '/package-lock.json')); |
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 use path.join
(or the sys equivalent) here, to make the path delimiter OS-agonstic
Co-authored-by: Ryan Waskiewicz <[email protected]>
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.
Tested on Windows + MacOS, looking good 😎
Left a few comments/nitpicks around typings, but nothing major
@@ -79,6 +79,8 @@ | |||
"@types/sizzle": "^2.3.2", | |||
"@types/webpack": "^4.41.26", | |||
"@types/ws": "^7.4.0", | |||
"@types/yarnpkg__lockfile": "^1.1.5", | |||
"@yarnpkg/lockfile": "^1.1.0", |
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.
As a dev dependency, how is this getting rolled up and put in the final compiler output?
) | ||
: ionicPackages.map(([k, v]) => `${k}@${v}`); | ||
try { | ||
packages = yarn ? await yarnPackages(sys, ionicPackages) : await npmPackages(sys, ionicPackages); |
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.
For my own knowledge, in what cases do we expect either of these await
calls to throw?
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.
If the lock files cannot be read (doesn't exist/incorrect file structure), that's when these should throw.
src/cli/telemetry/telemetry.ts
Outdated
async function getInstalledPackages( | ||
sys: d.CompilerSystem, | ||
config: d.Config | ||
): Promise<{ packages: string[]; packages_no_versions: string[] }> { |
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.
Can we camelCase pacakges_no_versions
please? I think we'd want to be using camelCase until it's time to send the snake_case value off to the aggregation service
* @returns a cleaned up representation without any qualifiers | ||
*/ | ||
function sanitizeDeclaredVersion(version: string) { | ||
return version.replace(/[*^~]/g, ''); |
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 is doing a global replace, which is probably fine?
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, that was the intent
src/cli/telemetry/telemetry.ts
Outdated
async function yarnPackages(sys: d.CompilerSystem, ionicPackages: [string, string][]) { | ||
const appRootDir = sys.getCurrentDirectory(); | ||
const yarnLock = sys.readFileSync(sys.resolvePath(appRootDir + '/yarn.lock')); | ||
const packageLockJson = sys.parseYarnLockFile(yarnLock); |
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 we rename this to yarnLockYml
or something similar?
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.
Can you walk me through the success/failure cases of this being read? Will packageLockJson
(as its named today) always be a truthy value, even when the reading fails?
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.
If reading fails, it throws and resolves back to the parent try/catch block. All other paths are truthy as you say.
src/cli/telemetry/telemetry.ts
Outdated
|
||
return ionicPackages.map(([k, v]) => { | ||
const identifiedVersion = `${k}@${v}`; | ||
let version = packageLockJson.object[identifiedVersion]?.version; |
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.
Since object
is of type any
, can we handle the case where it is undefined
/null
?
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 would handle that above, within the getInstalledPackages try/catch block.
Co-authored-by: Ryan Waskiewicz <[email protected]>
Co-authored-by: Ryan Waskiewicz <[email protected]>
Co-authored-by: Ryan Waskiewicz <[email protected]>
Co-authored-by: Ryan Waskiewicz <[email protected]>
Note that yarn 2+ are not supported |
this pr moves yarn dependencies from the `dependencies` section of our package-lock.json to `dev-dependencies`. In #3082, we didn't use the npm cli to move these from dependencies->dev-dependencies during iteration of the feature. this PR puts them in the correct place.
this pr moves yarn dependencies from the `dependencies` section of our package-lock.json to `dev-dependencies`. In #3082, we didn't use the npm cli to move these from dependencies->dev-dependencies during iteration of the feature. this PR puts them in the correct place.
Pull request checklist
Please check if your PR fulfills the following requirements:
npm run build
) was run locally and any changes were pushednpm test
) were run locally and passednpm run test.karma.prod
) were run locally and passednpm run prettier
) was run locally and passedPull request type
Please check the type of change your PR introduces:
What is the current behavior?
We're unable to understand how Yarn users work with Stencil today.
GitHub Issue Number: N/A
What is the new behavior?
Does this introduce a breaking change?
Testing
Other information