Creating react-file-type-icons package for v9 #35515
Conversation
…ileextension based filetype icons.
…/bigbadcapers/fluentui into caperez/sep-filetype-icon-update
…ethod used for file extensions
# Conflicts (merged and resolved): # packages/react-file-type-icons/src/FileIconType.ts # packages/react-file-type-icons/src/FileTypeIconMap.ts # packages/react-file-type-icons/src/getFileTypeIconProps.ts
… wrapped in an if statement to filter unwanted properties from the prototype guard-for-in
…gbadcapers/fluentui into caperez/filetype-icons-for-v9
bigbadcapers
requested review from
a team,
Jahnp,
JustSlone,
jurokapsiar and
tudorpopams
as code owners
|
hello @bigbadcapers , can you please provide more context about why this PR is needed? |
hey @tudorpopams i tagged you in a convo in Teams re this question, please lmk if we should do anything different, happy to adjust |
| "name": "@fluentui/react-file-type-icons", | ||
| "version": "8.15.2", | ||
| "description": "Fluent UI React file type icon set.", | ||
| "name": "@fluentui/react-file-type-icons-v8", |
There was a problem hiding this comment.
We can't really rename a public/published package. Also, I don't think we should ship a package with v8 in the name. What is the intention here?
There was a problem hiding this comment.
Agreed, check out the change a few lines down on 16..19. The change in line 2 is scoped to the yarn/npx workspace so everything compiles but the intent is that outwardly, the package in this folder location keeps publishing under the 8.x.x major semver, while the new package at packages/react-components/react-file-type-icons publishes unto the same @fluentui/react-file-type-icons NPM feed at 9.x.x
Is there a better way to deliver a v9 compatible package, ie by making changes "in-place" in the package here such that it conforms to v9 requirements and semantics needed by the folks in the Teams convo and others in the future? If so, my preference would be to overlay that here instead of having two packages for which i would have to maintain the FileTypeIconMap.ts and FileIconType enums on, for sure. Very happy to adjust if there is a better pattern to apply here to upgrades/migrations.
*the usage of the publishConfig attr is what i found researching how to do this, but i have ofc not been able to test live. will this approach work with our CI pipeline?
3 participants
masterbranchyarn changelocally