Closed severinbeauvais closed 4 years ago
@forgeuxGH5 Suggestions and ideas?
As a user I'd expect this to be on a Help/About page - I think the expected/logical location for this would be in the Account/setting drop-down built by Relationships - so we probably need to talk to them here. I think they are handling the footer too right?
Yes, Relationships is providing the header and footer, but it would be easy enough to optionally pass them a callback (or just value) that they could display somewhere.
However, I just chatted to Jeremy about providing an About page or something like that and it's not clear that there's a real requirement for this. A couple of other options then:
I'm going to let this sit for now and see if any other ideas come up or if this is really not needed.
Target audience for this information is, I assume, the development team and, in the future, the operations team. This feels like a very-low effort - medium value idea. Might it be a good use for a console.info message?
@bryan-gilbert Good point and great idea!
I heard a new package is needed to cleanly/easily extract the version number from the package.json or manifest, but after that it's easy to console.log the version number on app start.
I found this: https://webpack.js.org/plugins/define-plugin/
My pref is to keep it simple and not introduce another tool unless there is a greater need. Keeping this low effort is key or the idea my languish. If we read from package version then we'll have appropriate versions for dev, test and prod by default. Then later as our CI/CD pipeline improves the version in the package.json might be automatically updated. Something like https://stackoverflow.com/questions/58311847/github-action-for-updating-package-json
https://stackoverflow.com/questions/9153571/is-there-a-way-to-get-version-from-package-json-in-nodejs-code About half way down ... two options
const { version } = require('./package.json');
const version = process.env.npm_package_version;
Yet, let's watch that warning about browserfy and including package.json in our bundles.
Using "require" probably doesn't work in build time or when deployed and may expose package.json (which some deem to be a security risk).
The second option is good but we need to inject PACKAGE_VERSION into the environment... Which can be done by Webpack configuration. Per Thor:
Something like
JSON.parse(unescape(process.env.PACKAGE_JSON || '%7Bversion%3A0%7D')).version
You could add something like this to vue.config.js:const fs = require('fs') const packageJson = fs.readFileSync('./package.json') const version = JSON.parse(packageJson).version || 0 module.exports = { configureWebpack: { plugins: [ new webpack.DefinePlugin({ 'process.env': { PACKAGE_VERSION: '"' + version + '"' } }) ] } }
Also I suggest outputting a message like this: console.info(`** This is ${name} v${version}. **`)
This ticket updates:
I didn't finish this in Sprint 36 so I moved it to Sprint 37. Also I updated the estimate to time taken (which involved post-design discussion between developers :P ).
Screenshots:
The information icon:
The tooltip (when hovering over the icon):
(NB - sbc-common-components is now 2.3.3 or higher)
Description:
The UIs (Cooperatives, Create Business, etc) have an internal version number (see package.json) that should be displayed somewhere for ease of diagnostics and trouble-shooting.
For example, the version number could be displayed in the footer. (Or a link to an About page with the main version number and any notable imported package version numbers could be displayed.)
Acceptance for a Task:
Add/ maintain selectors for QA purposesnot applicableTest coverage acceptablenot changed