Harrison Healey
f6341a17ba
* Start moving user agent utils into shared package * Remove inobounce and stop exporting isIosSafari Based on some quick testing on my phone, inobounce is no longer needed. Both local and Community: 1. Let you overscroll on the landing and login pages 2. Don't overscroll in a channel, a thread, or the LHS while fully zoomed out 3. Do let you overscroll when zoomed in That also lets me reduce the size of the interface for utils/user_agent. * Remove unneeded exports and unused functions * Remove outdated workarounds from FileUpload component These were only needed to support a 10 year old version of iOS Chrome and the classic app. * Remove useOrientationHandler This was added in https://github.com/mattermost/mattermost-webapp/pull/2504, but I don't think the extra complexity is worth keeping it around when we mostly support mobile view for desktop accessibility reasons. * Replace isIosWeb/isAndroidWeb with isIos/isAndroid These were previously needed to differentiate between the mobile web app and the classic app. * Replace isMobileApp with isMobile Similar to the last commit, we used to need to differentiate between the mobile web and the classic app. For most places, I just replaced isMobileApp with isMobile, but I removed the check in ProductMenuList because we want to show that link on mobile web. * Move isInternetExplorer and isEdge out of the shared package Those should be removed, so I don't want to include them in the shared package at all. I also renamed isChromiumEdge to just isEdge since that should be its name once the old ones are removed. * Change how functions are re-exported to fix tests * Update web app code to use shared user agent utils directly * Removed useless mock * Fix how tests mock utils/user_agent now that it's fully moved * Actually export user_agent utils from shared package
Mattermost Web App
This folder contains the client code for the Mattermost web app. It's broken up into multiple packages each of which either contains an area of the app (such as playbooks) or shared logic used across other packages (such as the packages located in the platform directory). For anyone who's used to working in the mattermost/mattermost-webapp repo, most of that is now located in channels.
npm Workspaces
To interact with a workspace using npm, such as to add a dependency or run a script, use the --workspace (or --workspaces) flag. This can be done when using built-in npm commands such as npm add or when running scripts. Those commands should be run from this directory.
# Add a dependency to a single package
npm add react --workspace=playbooks
# Build multiple packages
npm run build --workspace=platform/client --workspace=platform/components
# Test all workspaces
npm test --workspaces
# Clean all workspaces that have a clean script defined
npm run clean --workspaces --if-present
To install dependencies for a workspace, simply run npm install from this folder as you would do normally. Most packages' dependencies will be included in the root node_modules, and all packages' dependencies will appear in the package-lock.json. A node_modules will only be created inside a package if one of its dependencies conflicts with that of another package.
Useful Links
- Developer setup, now included with the Mattermost server developer setup
- Web app developer documentation
Dependency Changes
Any PR that modifies package.json or package-lock.json needs extra scrutiny:
- No duplicate libraries. Before adding a new dependency, check whether an existing one already covers the same use case. Multiple libraries for the same purpose (e.g., two different date pickers, or Bootstrap 3 and Bootstrap 4 simultaneously) create long-term upgrade pain.
- License check. New dependencies must not use GPL or similarly restrictive licenses. Dependencies with no license at all should also be flagged.
- Justify the addition. A new dependency should solve a real problem that existing code or dependencies don't already address. Push back on adding packages for trivial functionality.
- Version conflicts. Check whether the new dependency introduces conflicting peer dependency versions. Cascading version conflicts are expensive to untangle later and have historically blocked upgrades for months.