As a developer integrating the listing-widget using
I need static js and css filenames since I link to them directly in my webpage. The filenames should not change unless there is a new major version, in which case the new version must have a new filename and the existing version remain available.
@saumier I have done some research and found that by using a package called react-app-rewired we can create the .js and .css files with the name of our choice appended with the version in package.json.
I did a test build in my local, and this was the result -
name of js file - widget-0.1.0.js
name of CSS file - widget-0.1.0.css
version in package.json - "version": "0.1.0"
I believe this will solve the issue. Please let me know what you think of this approach.
Also, I have some questions -
1 - Since we want the file name to change only when releasing a major version, I was thinking about running "npm version major" before such updates so that the file names will remain the same for all other patch updates and minor updates. What are your thoughts on this
approach?
Or should the version be updated automatically during the production deployment? But that way the file name will change during each production release.
2 - Should all versions be available simultaneously, or only the latest version and the previous major one?
3 - How will minor or patch updates be handled?
You can find the changes I implemented to achieve this here: feature/issue-45
@SyamBabu-M The version in the file name or path should not include patches (third part of semantic versioning) which are fixes that should not require any change from the client. I think it is good to have the middle number which is for new non-breaking features included in the filename or path but it is the major (high risk and breaking changes) that must be in the filename or path. How do you propose we do this?
@troughc @SyamBabu-M As discussed at the standup today, lets only use the major version in the filename/path. This way the client will be able to automatically get patches and minor non-breaking updates. We will maintain previous major versions so the client can decide when and if they want to upgrade their major version.
@saumier, I have updated the develop as per requirement. Here is a summary -
1 - Updated the code to ensure that all build files are now organized within a directory named "v[major-version-number]".
2 - Refactored the build file outputs of JavaScript and CSS files to follow the naming format "widget-[major-version-number]".
3 - Refactored the deployment script to ensure that the previous major version is preserved during the release process. Only current version and previous version will be available in the bucket. (If I have v1 and v0 in the bucket right now and if I were to release v2, v0 will be deleted, but v1 and v2 will be available)
4 - Attempted to implement automated versioning using semantic-release. Did not succeed as I ran into issues related to the node version.
Please check the staging S3 bucket to ensure everything is in order.
Here is the PR for production that includes all the above mentioned changes.
As a developer integrating the listing-widget using
@troughc This is high priority for Syam because it is needed by Verb interactive (for Destinations Canada website, for NAC Osaka)
@saumier I have done some research and found that by using a package called react-app-rewired we can create the .js and .css files with the name of our choice appended with the version in package.json. I did a test build in my local, and this was the result - name of js file - widget-0.1.0.js name of CSS file - widget-0.1.0.css version in package.json - "version": "0.1.0"
I believe this will solve the issue. Please let me know what you think of this approach.
Also, I have some questions -
1 - Since we want the file name to change only when releasing a major version, I was thinking about running "npm version major" before such updates so that the file names will remain the same for all other patch updates and minor updates. What are your thoughts on this approach? Or should the version be updated automatically during the production deployment? But that way the file name will change during each production release.
2 - Should all versions be available simultaneously, or only the latest version and the previous major one?
3 - How will minor or patch updates be handled?
You can find the changes I implemented to achieve this here: feature/issue-45
here are the references I used - 1 - https://docs.npmjs.com/cli/v8/commands/npm-version 2 - https://www.geeksforgeeks.org/introduction-semantic-versioning/ 3 - https://github.com/timarney/react-app-rewired/issues/301
@SyamBabu-M The version in the file name or path should not include patches (third part of semantic versioning) which are fixes that should not require any change from the client. I think it is good to have the middle number which is for new non-breaking features included in the filename or path but it is the major (high risk and breaking changes) that must be in the filename or path. How do you propose we do this?
@saumier This sounds great. I am looking into integrating this into our github action.
I am hoping we will only preserve existing versions for major releases. Or do we need to preserve the existing versions during minor updates?
@troughc @SyamBabu-M As discussed at the standup today, lets only use the major version in the filename/path. This way the client will be able to automatically get patches and minor non-breaking updates. We will maintain previous major versions so the client can decide when and if they want to upgrade their major version.
@saumier, I have updated the develop as per requirement. Here is a summary -
1 - Updated the code to ensure that all build files are now organized within a directory named "v[major-version-number]". 2 - Refactored the build file outputs of JavaScript and CSS files to follow the naming format "widget-[major-version-number]". 3 - Refactored the deployment script to ensure that the previous major version is preserved during the release process. Only current version and previous version will be available in the bucket. (If I have v1 and v0 in the bucket right now and if I were to release v2, v0 will be deleted, but v1 and v2 will be available) 4 - Attempted to implement automated versioning using semantic-release. Did not succeed as I ran into issues related to the node version.
Please check the staging S3 bucket to ensure everything is in order. Here is the PR for production that includes all the above mentioned changes.