Alaska Airlines
A better way to communicate and manage Auro dependencies #505
Replies: 5 comments 7 replies
-
|
As listed, just about EVERY repo has a dependency on Icons and WCSS. I am not recommending that we update every repo with each release of these tools. Every repo should have the dependency listed with the That being said, I would suggest that at least once a 'sprint' cycle we look to update all the repos based on the releases that cycle. |
Beta Was this translation helpful? Give feedback.
-
|
Something we could look to automate is cycling through each repo and performing a surgical npm update that will only update Auro packages and run a build to ensure there are no issues. |
Beta Was this translation helpful? Give feedback.
-
|
Using BASH and the npm-check-updates tool, I created the following script that will update all the dependents of the Auro Icons repo. function updateDependents_icons {
## declare an array variable
declare -a arr=("datetime/" "carousel/" "checkbox/" "accordion/" "dialog/" "alert/" "badge/" "hyperlink/" "icon/" "pane/" "menu/" "avatar/" "card/" "input/" "nav/" "backtotop/" "combobox/" "datepicker/")
## now loop through the above array
for i in "${arr[@]}"
do
echo -e "\n$i\n"
command cd ~/src/auro/"$i"
command git checkout master
command git checkout main
echo -e "updating repo from remote"
command git pull
command npx npm-check-updates @alaskaairux/icons --peer -u -d --verbose --doctorTest 'npm run build'
command git add --all
sleep 1
command git commit --no-verify -m "perf: update @aurodesignsystem dependencies"
echo -e "Commit added to Git\n"
echo -e "Pushing to the remote\n"
sleep 2
command git push origin $(git branch-name) -u
echo -e "Update pushed to the remote\n"
command open https://github.com/AlaskaAirlines/auro-"$i"actions
done
}Maintaining this list of dependents is something we should look into automating as well. Doing some research on this, npm is more concerned about managing dependencies versus dependents. There are few tools I came across that even considered this kind of resource management. In this scenario, npm-check-updates filters out only Regarding peer dependencies, as long as each dependency is set with a Give the following example. In a project the first element installed is auro-datetime. This element has a peer dependency on Icons and WCSS. The After running the install, versions Given this information, while we do want to keep all our dependencies up to date and ensure that they still work as expected, I recommend the following.
|
Beta Was this translation helpful? Give feedback.
-
Digging deeper, there are no utilities for this because the process of Even so, if a user needs to redefine the version of a dependency, this again is done at the consumer's end using the override feature. |
Beta Was this translation helpful? Give feedback.
-
|
Documenting this as known info, but pertains to this conversation. A tool Auro uses when building dependencies is For example, Auro makes good use of the caret From npm's perspective running While there is a responsibility from Auro to maintain dependencies and ensure that our components work with the latest Auro releases, e.g. an Auro component having a dependency on another Auro component or library, the maintenance of dependencies on the consumer end is up to the consumer. We cannot do that for them. What does this end up looking like? Within each sprint timeline, the Auro team will ensure, based on the table above, that as lower-level Auro deliverables are updated, their dependents are also updated to ensure compatibility. Additionally, as changes happen in core libraries, e.g. tokens or WCSS, these resources are NOT released until their compatibility with all other dependents are updated to support their release. This especially holds true for any major releases. |
Beta Was this translation helpful? Give feedback.
-
|
Something a little confusing when interacting with other developers is, it is reported that a component that has a nested dependency of When npm installs these dependencies, the tree should look like this. Illustrating that the ├─┬ [email protected]
│ ├── [email protected] deduped
├─┬ [email protected]Given this, even if a version defined is behind the currently released version, npn will install the current version in both cases. The only reason I can understand that this is happening is if the consumer of the package has not properly updated their dependencies or has cherry-picked their updates allowing the package-lock.json to have inappropriate refs. Another cause of incorrect dependencies being loaded is from consumers not clearing out their node_modules directory properly. In any case, when confronted with situations where there are conflicting versions in an install, the consumer should be requested to dump their node_modeules and package-lock.json and perform a fresh npm install. |
Beta Was this translation helpful? Give feedback.
-
|
As of For the purpose of easy management by consumers, it has been a preference for Auro dependencies to be listed as peerDependencies unless it is a specific dependency that the consumer would not normally install. E.g. auro-datepicker has a dependency on auro-input. It is fair to say that the consumer will also want auro-input installed for other reasons outside of the use of datepicker. In that case, it is reasonable to conclude that listing auro-input as a peerDependency is appropriate. One of the reasons for NOT listing as a peerDependency was auto-installing which is not an issue since v7. There are few cases, if any, where a parent element has a strict dependency on another element's specific version. We should avoid that at all opportunities. E.g. if a primitive element like auro-input has an update with a feature release, it MUST be validated and supported by all consuming elements. For example, it would be the responsibility of the Auro team to ensure that any updates to auro-input is 100% compatible with the currently released auro-datepicker BEFORE release. In the use case where an Auro engineer will want to lock in a dependency at a version, then this MUST include the work to re-register that component under a different name as illustrated by auro-nav. Given this information, I would conclude that all auro components move all their auro component dependencies to peerDependencies unless there is a specific reason for version lock. But given the info about how SemVer works, the version lock is only restricting MAJOR updates. The following snippet is from auro-nav's list of dependencies. "dependencies": {
"@aurodesignsystem/auro-button": "^7.2.7",
"@aurodesignsystem/auro-hyperlink": "^3.5.6",This snippet is from npm listing dependencies post-install. ├─┬ @aurodesignsystem/[email protected]
│ ├── @aurodesignsystem/[email protected] deduped
│ ├── @aurodesignsystem/[email protected] dedupedUnless we are specifically version locking a package version to be less than or equal to a specific version, npm install or npm update will always try to increase the minor or patch version. |
Beta Was this translation helpful? Give feedback.
-
|
More data for this conversation. It's been brought up about how auro-combox essentially fixes the version it has installed. In the "dependencies": {
"@alaskaairux/icons": "^4.36.2",
"@aurodesignsystem/auro-dropdown": "^2.10.2",
"@aurodesignsystem/auro-input": "^2.17.5",
"@aurodesignsystem/auro-menu": "^3.11.1",
"chalk": "^5.3.0",
"lit": "^3.1.2"
},The supporting code that generates unique names import { AuroDropdown } from '@aurodesignsystem/auro-dropdown/src/auro-dropdown.js';
import dropdownVersion from './dropdownVersion.js';
import { AuroInput } from '@aurodesignsystem/auro-input/src/auro-input.js';
import inputVersion from './inputVersion.js';
...
/**
* Generate unique names for dependency components.
*/
const versioning = new AuroDependencyVersioning();
this.dropdownTag = versioning.generateTag('auro-dropdown', dropdownVersion, AuroDropdown);
this.inputTag = versioning.generateTag('auro-input', inputVersion, AuroInput);The end result in the browser ... 
This is what is loaded via npm for the combobox component ├─┬ @aurodesignsystem/[email protected]
│ ├── @alaskaairux/[email protected] deduped
│ ├── @aurodesignsystem/[email protected] deduped
│ ├── @aurodesignsystem/[email protected] deduped
│ ├── @aurodesignsystem/[email protected] deduped
│ ├── @aurodesignsystem/[email protected] deduped
│ ├── @aurodesignsystem/[email protected] deduped
│ ├── [email protected] deduped
│ └── [email protected] dedupedThere is a flaw in this as the version typed into the DOM is NOT reflective of the version installed. The problem here is that we cannot base this value on internal understanding. As long as we set dependencies with a The only way to know for sure what is happening is to use something like The important thing to take away from here is that the solution provided here, in theory, does remove issues with registration and potential version clashing. But... this is difficult to prove. 
|
Beta Was this translation helpful? Give feedback.
-
RecommendationWhen it comes to having dependencies on other auro components.
As you can see in the following list, multiple Auro dependencies are loaded under a component install, but are then deduped ├─┬ @aurodesignsystem/[email protected]
│ ├── @aurodesignsystem/[email protected] deduped
│ ├── @aurodesignsystem/[email protected] deduped
│ ├── [email protected] deduped
│ └── [email protected] deduped
├─┬ @aurodesignsystem/[email protected]
│ ├── @alaskaairux/[email protected] deduped
│ ├── @aurodesignsystem/[email protected] deduped
│ ├── @aurodesignsystem/[email protected] deduped
│ ├── [email protected] deduped
│ └── [email protected] deduped
├─┬ @aurodesignsystem/[email protected]
│ ├── @alaskaairux/[email protected] deduped
│ ├── @aurodesignsystem/[email protected] deduped
│ ├── @aurodesignsystem/[email protected] deduped
│ ├── [email protected] deduped
│ ├── [email protected] deduped
│ └── [email protected]When looking into the npm maintenance habits greatly vary from dev to dev. Moving common dependencies to |
Beta Was this translation helpful? Give feedback.
-
|
I think this is great that you brought this up. I admit, my understanding of dependencies and how they are consumed is not strong, but I have noticed a numerous amount of inconsistencies with how our dependencies are listed from component to component. If you are saying that having our components listed under |
Beta Was this translation helpful? Give feedback.
-
|
There may be a flaw in the current version-lock strategy. After reviewing this PR I see a slight flaw. The dependencies are listed with the The scripts/version.mjs functionality requires a build in order to generate the appropriate version tag on the element. That all works great and even accounts for a simple The potential issue I am seeing is that a user could run A potential fix is to set the dependency using the |
Beta Was this translation helpful? Give feedback.
-
|
Teams typically have a habit of using the default Additionally, this step doesn't always dedupe versions. E.g. multiple installs of a single dependency with nested refs may have different versions. The only way to really ensure that there is no node crud is to run |
Beta Was this translation helpful? Give feedback.
-
There is a small set of elements that have either nested or peer dependencies on other Auro elements. The issue here is that when one element is updated and other elements have a dependency on that released element, the dependents should be updated as well.
Here is a quick table of elements and their dependencies. We need to find a better way to manage this data and assist with managing updates as well.
Auro component dependency map
The following is a mapping of repositories and their direct and peer dependencies.
Beta Was this translation helpful? Give feedback.
All reactions