-
-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor(web/engine): Moves common utility functions into separate web-utils
package
#3130
Conversation
common/predictive-text/package.json
Outdated
}, | ||
"dependencies": { | ||
"@keymanapp/keyboard-processor": "^14.0.76", | ||
"@keymanapp/web-utils": "^14.0.76", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The number one reason for this PR is right here.
This allows the lm-layer to link in a simple "leaf" package in order to access our KMW string extensions, rather than the whole keyboard-processor package... which then links in its dependencies, etc. This has generally been the breaking point for long paths on #3098 (deprecated) and #3119 and is currently blocking #3128 from being a clean split.
Refer to #3119 (comment) for an example path - almost all instances where this have arisen (so far) are due to the dependency this one change directly addresses and greatly reduces.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This also helps to clean up a number of the <reference path />
links that were introduced during the refactor, as the most common multi-referenced code is in this package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Nice refactor.
By extracting some of the utility functions and definitions out of
keyboard-processor
, we can alleviate a bit of the crazynpm link
pathing we've been seeing in our other recent PRs. The only dependency here is for the typescript compiler.I'm also strongly considering moving
engineDeviceSpec.ts
from thetext
namespace to theutils
namespace and intoweb-utils
, as it's utilized by a number of our development tools as well.DeviceSpec
. (Will take a more than a few edits, though simple, to fix.)Device
, but that's already taken by DOM-aware KMW'sDevice
type, which also does active detection and such.