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

Ace version fix #226

Merged
merged 12 commits into from
Apr 30, 2019
Merged

Ace version fix #226

merged 12 commits into from
Apr 30, 2019

Conversation

danielweck
Copy link
Member

Fixes #198

package.json from @daisy/ace-config used as authoritative source of truth for global Ace version, used in CLI(s) (via meow), verbose logger (via winston), and JSON/HTML report (via @daisy/ace-report).

…ruth for global Ace version, used in CLI(s) (meow), verbose logger (winston), and JSON/HTML report.
@danielweck
Copy link
Member Author

PS: this bumps Ace to version 1.0.3 :)

@danielweck
Copy link
Member Author

Note that I disabled Snyk Travis checks, which used to break the PR builds unnecessarily. See:
https://travis-ci.org/daisy/ace/pull_requests

The PR "homepage" shows the Snyk warnings anyway, so the project lead can check this info before deciding to merge.

Copy link
Member

@rdeltour rdeltour left a 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?

CHANGELOG.md Outdated Show resolved Hide resolved
packages/ace-cli/package.json Show resolved Hide resolved
packages/ace-report/package.json Show resolved Hide resolved
website/config.toml Outdated Show resolved Hide resolved
@danielweck
Copy link
Member Author

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:

  • @daisy/ace-config ~~~~~~~~~~~~~~~~~
    • (no @daisy/* deps)
  • @daisy/ace-core
    • @daisy/ace-report-axe
    • @daisy/puppeteer-utils
    • @daisy/ace-report
    • @daisy/ace-config <<------------------------
    • @daisy/epub-utils
    • @daisy/jest-puppeteer
  • @daisy/ace-cli
    • @daisy/ace-logger
    • @daisy/ace-core
    • @daisy/ace-config <<------------------------
  • @daisy/ace-http
    • @daisy/ace-core
    • @daisy/ace-logger
    • @daisy/ace-config <<------------------------
  • @daisy/ace-logger
    • @daisy/ace-config <<------------------------
  • @daisy/ace-report-axe
    • @daisy/ace-report
  • @daisy/ace-report
    • @daisy/ace-config <<------------------------
  • @daisy/ace
    • @daisy/ace-http
    • @daisy/ace-cli
    • @daisy/ace-core
  • @daisy/jest-puppeteer
    • @daisy/puppeteer-utils

...vs. if we switch to ace-core's package.json to carry the "global" Ace version:

  • @daisy/ace-config
    • (no @daisy/* deps)
  • @daisy/ace-core ~~~~~~~~~~~~~~~~~
    • @daisy/ace-report-axe !!========================
    • @daisy/puppeteer-utils
    • @daisy/ace-report !!========================
    • @daisy/epub-utils
    • @daisy/jest-puppeteer
  • @daisy/ace-cli
    • @daisy/ace-logger
    • @daisy/ace-core <<------------------------
    • @daisy/ace-config
  • @daisy/ace-http
    • @daisy/ace-core <<------------------------
    • @daisy/ace-logger
  • @daisy/ace-logger
    • @daisy/ace-config
  • @daisy/ace-report-axe
    • @daisy/ace-report
  • @daisy/ace-report
    • @daisy/ace-core <<------------------------
    • @daisy/ace-config
  • @daisy/ace
    • @daisy/ace-http
    • @daisy/ace-cli
    • @daisy/ace-core <<------------------------
  • @daisy/jest-puppeteer
    • @daisy/puppeteer-utils

As you can see:

  • @daisy/ace-core => @daisy/ace-report-axe => @daisy/ace-core CYCLIC
  • @daisy/ace-core => @daisy/ace-report-axe => @daisy/ace-report => @daisy/ace-core CYCLIC

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

I was concerned about cyclic dependencies

Right, this could be an issue indeed. Just thinking out loud: what about creating a package that would do just this? (e.g.ace-version or ace-meta?). Given that adding package is pretty lightweight with the monorepo setup… That way we don't overload ace-config, and remove the cyclic deps issue.

@danielweck
Copy link
Member Author

A new package ace-meta now provides version info via its package.json (authoritative source of truth for global Ace version). I cleaned-up the PR, reducing it to what is strictly necessary for this bug fix. Could you please review?

Tested with:

  • node packages/ace[-cli]/bin/ace --version (shows 1.0.3)
  • node packages/ace[-cli]/bin/ace --verbose --force --outdir PATH_TO_DEST_DIR PATH_TO_SRC_EPUB (shows 1.0.3 in verbose console log, and in generated JSON/HTML report)

Copy link
Member

@rdeltour rdeltour left a 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",
Copy link
Member

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?

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, a package should explicitly declare all its direct dependencies.

@danielweck
Copy link
Member Author

Is this a suitable commit message?

fix: correct global Ace version.

A consistent Ace version is now provided via the command line, in the verbose logger, and into the generated JSON/HTML reports. The new ace-meta package is the authoritative source of truth for versioning information.

PR closes #198

@rdeltour
Copy link
Member

looks good!

@danielweck danielweck merged commit 822469f into master Apr 30, 2019
@danielweck danielweck deleted the fix/versions branch April 30, 2019 09:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Ace version different from command line to HTML report
2 participants