Listing Widget static filenames

[saumier]

As a developer integrating the listing-widget using

I need static js and css filenames (urls) since I link to them directly in my webpage. The filenames (urls) should not change unless there is a new major version, in which case the new version must have a new filename (url) and the existing version remain available.

[saumier]

@troughc This is high priority for Syam because it is needed by Verb interactive (for Destinations Canada website, for NAC Osaka)

[SyamBabu-M]

@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 - timarney/react-app-rewired#301

[saumier]

@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?

[SyamBabu-M]

@saumier This sounds great. I am looking into integrating this into our github action.

in which case the new version must have a new filename and the existing version remain available.

I am hoping we will only preserve existing versions for major releases. Or do we need to preserve the existing versions during minor updates?

[saumier]

@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.

[SyamBabu-M]

@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.

[saumier]

@SyamBabu-M I made a couple of comments in the code review. I don't think we need to change both the filenames and the path. I prefer just the path. And please do not delete any of the older major versions.

Also please add a description of the release process to the readme to explain how to change the version number and how it impacts the build and the S3 bucket.

Did you test the iFrame to ensure that it still works with the new file names?

[SyamBabu-M]

@saumier I have added all the requested changes. Please look into those.

Did you test the iFrame to ensure that it still works with the new file names?

yes they are working fine

[SyamBabu-M]

@saumier I have updated the readme.md.
Here is the PR
#51

[saumier]

@SyamBabu-M Please see comment in PR. Almost there. Please test with the urls to make sure they are working.

[saumier]

@SyamBabu-M Please merge both PRs and test the new S3 bucket with both the current version of iframe (using root directory) and the new v0 directly with both the div and iframe approaches. Thx.

[SyamBabu-M]

@saumier I merged the pr and tested out the iframe and div approach in both v0 and the current version. Everything is working fine.