-
Notifications
You must be signed in to change notification settings - Fork 22
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
Ace version fix #226
Ace version fix #226
Conversation
…ruth for global Ace version, used in CLI(s) (meow), verbose logger (winston), and JSON/HTML report.
PS: this bumps Ace to version |
… see Snyk warnings in PRs anyway)
Note that I disabled Snyk Travis checks, which used to break the PR builds unnecessarily. See: The PR "homepage" shows the Snyk warnings anyway, so the project lead can check this info before deciding to merge. |
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'm wondering if it wouldn't make more sense to use ace-core
as the authoritative source of truth for the version. ace-config
is a set of utilities which may be quite stable in time (i.e. may not need to be artificially updated for each release), whereas ace-core
really represents the core functionality. WDYT?
I was concerned about cyclic dependencies. This PR:
...vs. if we switch to
As you can see:
Although in many cases this doesn't cause the NodeJS interpreter to fail, further down the compiler chain (e.g. WebPack etc. bundlers) this can cause headaches. What do you think? |
…ven monorepo with single root node_modules containing flat deps packages, and single root yarn.lock ... package-lock.json would possibly catch these discrepancies in each of the monorepo's individual packages? ... depends on the build process, really)
Right, this could be an issue indeed. Just thinking out loud: what about creating a package that would do just this? (e.g. |
A new package Tested with:
|
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.
Looks good to me!
I just have a question about the need to explicitly declare transitive dependencies, but this is not critical to this PR.
Also, do not forget to squash and update the commit message when merging :-)
@@ -18,8 +18,10 @@ | |||
"main": "lib/index.js", | |||
"bin": "bin/ace.js", | |||
"dependencies": { | |||
"@daisy/ace-config": "^1.0.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.
Do we need an explicit dependency to ace-config
, since we're transitively depending on it via ace-core
?
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, a package should explicitly declare all its direct dependencies.
Is this a suitable commit message?
|
looks good! |
Fixes #198
package.json
from@daisy/ace-config
used as authoritative source of truth for global Ace version, used in CLI(s) (viameow
), verbose logger (viawinston
), and JSON/HTML report (via@daisy/ace-report
).