microsoft
feat: adopt single version policy for monorepo dependencies
Story 🧚♀️
Actual behavior:
Currently every packages includes exact same list of devDependencies/
"devDependencies": {
"@fluentui/babel-make-styles": "9.0.0-beta.4",
"@fluentui/eslint-plugin": "*",
"@fluentui/jest-serializer-make-styles": "9.0.0-beta.4",
"@fluentui/react-conformance": "*",
"@fluentui/react-conformance-make-styles": "9.0.0-beta.4",
"@fluentui/scripts": "^1.0.0",
"@types/enzyme": "3.10.3",
"@types/enzyme-adapter-react-16": "1.0.3",
"@types/react-test-renderer": "^16.3.0",
"@types/react": "16.9.42",
"@types/react-dom": "16.9.10",
"enzyme": "~3.10.0",
"enzyme-adapter-react-16": "^1.15.0",
"react": "16.8.6",
"react-dom": "16.8.6",
"react-test-renderer": "^16.3.0"
},
Expected behavior:
All devDependencies should adhere to "single version policy in monorepo". Why ?
- every devDependency is defined in root
package.json- TBD: use pinned version to align with yarn.lock ( this might be detrimental in terms of modules de-dupe though)
- if package really needs to opt out, it will specify different version of devDependency within its package.json to prevent hoisting. (this should be only last resort and for temporary time period )
Tasks
- [ ] write migration https://github.com/microsoft/fluentui/pull/26437
- [ ] migrate to lastest syncpack
- [ ] update existing plol generator
- [ ] execute migration in batch
- [ ] add lint checks to prevent violations
Related issues
- https://github.com/microsoft/fluentui/issues/20799
- https://github.com/microsoft/fluentui/pull/19799
Because this issue has not had activity for over 180 days, we're automatically closing it for house-keeping purposes.
Still require assistance? Please, create a new issue with up-to date details.
Rules:
flowchart TB
RPD[root package.json prodDep]
RPDD[root package.json devDep]
PPD[library package.json prod]
PDD[library package.json devDep]
D[devDep]
P[prodDep]
PDD --> B{is a workspace package ?}
B -->|"no"| RFL["remove from lib"] --> RPDD --> E["end"]
B -->|"yes"| KKK["keep and use *"] --> E
PPD --> |"keep in lib"| RPD
Why do we need to specify "dependencies" as well within root package.json ?
The motivation behind this is to have every non transient dependency used within our production (as well non production code which is covered by devDependencies) within root package.json for 2 reasons:
- security audit
- (in future) dependencies auto generation by nx which uses root package.json#dependencies versions https://github.com/nrwl/nx/issues/9219
One might question this approach as it will create duplicates as one will have to specify same dependency at two places - library package.json and root package.json. While that's a valid concern it is low cost to achieve full prod deps transparency. Also it will be supported by tooling (ideally syncpack) to adhere to this pattern.
What to do if package is both production and dev dependency ?
Prod dependency has always higher priority ( if clashes occur )
Library/App that specifies devDependency on workpsace package uses *
After we migrate to nx, all devDeps fields will be removed, because unlike lage, nx will properly resolve within monorepo dependency graph
What about root package.json version format?
All deps and devDeps in root use strict version, pinned to lowest caret specified in lib package
- eg: (lib) ^4.7.1 --> (root) 4.7.1
Exceptions:
stylis
react-northstar is using v3 while @fluentui/react-northstar-emotion-renderer is on v4. Because performance downgrade in v4 there are no plans to migrate react-northstar to v4
react / react-dom
whole monorepo is using react v17 ATM. to be able to verify fluent compatibility on newer version we also have React 18 within 2 apps as dependency, thus those can't/won't be normalized to SVP.
axe-core
@fluentiu/react-builder uses v3, while jest-axe depends on axe-core 4. Axe-core is not being used directly in whole monorepo besides react-builder package.
This can be normalized by additional work. https://github.com/microsoft/fluentui/issues/20799
- fix https://github.com/microsoft/fluentui/pull/26453
REMARKS:
Until @types/jest-axe will not ship new versions that specify proper axe-core as dependency we need to use resolutions: "@types/jest-axe/axe-core": "4.2.1",. ATM there is only @types/[email protected] whilst latest jest-axe is version 7.
tslib
web-components are on old tslib v1. The reasoning behind was that some OSS folks on FAST were using Typescript v3.9.
Based on discussion with WC team we can bump to v2 and unify tslib version
- fix https://github.com/microsoft/fluentui/pull/26457
Because this issue has not had activity for over 180 days, we're automatically closing it for house-keeping purposes.
Still require assistance? Please, create a new issue with up-to date details.
![microsoft-github-policy-service[bot] avatar](https://avatars.githubusercontent.com/in/95686?v=4 "Published by a pub.dev verified publisher"){kind=small}
Because this issue has not had activity for over 180 days, we're automatically closing it for house-keeping purposes.
Still require assistance? Please, create a new issue with up-to date details.
Because this issue has not had activity for over 180 days, we're automatically closing it for house-keeping purposes.
Still require assistance? Please, create a new issue with up-to date details.
Because this issue has not had activity for over 180 days, we're automatically closing it for house-keeping purposes.
Still require assistance? Please, create a new issue with up-to date details.
Because this issue has not had activity for over 180 days, we're automatically closing it for house-keeping purposes.
Still require assistance? Please, create a new issue with up-to date details.
Because this issue has not had activity for over 180 days, we're automatically closing it for house-keeping purposes.
Still require assistance? Please, create a new issue with up-to date details.
Because this issue has not had activity for over 180 days, we're automatically closing it for house-keeping purposes.
Still require assistance? Please, create a new issue with up-to date details.
Because this issue has not had activity for over 180 days, we're automatically closing it for house-keeping purposes.
Still require assistance? Please, create a new issue with up-to date details.
Because this issue has not had activity for over 180 days, we're automatically closing it for house-keeping purposes.
Still require assistance? Please, create a new issue with up-to date details.
Because this issue has not had activity for over 180 days, we're automatically closing it for house-keeping purposes.
Still require assistance? Please, create a new issue with up-to date details.
Because this issue has not had activity for over 180 days, we're automatically closing it for house-keeping purposes.
Still require assistance? Please, create a new issue with up-to date details.
Because this issue has not had activity for over 180 days, we're automatically closing it for house-keeping purposes.
Still require assistance? Please, create a new issue with up-to date details.
Because this issue has not had activity for over 180 days, we're automatically closing it for house-keeping purposes.
Still require assistance? Please, create a new issue with up-to date details.
This issue has not had activity for over 180 days! We're adding Soft close label and will close it soon for house-keeping purposes. Still require assistance? Please add comment - "keep open".
This issue has not had activity for over 180 days! We're adding Soft close label and will close it soon for house-keeping purposes. Still require assistance? Please add comment - "keep open".