okta-auth-js
okta-auth-js copied to clipboard
Installing this package fails on M1 mac: can't build `microtime`
Describe the bug?
We want to add okta to RedwoodJS (see https://github.com/redwoodjs/redwood/pull/5088), but after I add this package (@okta/okta-auth-js
) yarn install
fails because microtime@npm:3.0.0
can't be built:
➤ YN0009: │ microtime@npm:3.0.0 couldn't be built successfully (exit code 1, logs can be found here: /private/var/folders/dt/yks4v5m53k114qxgz6jh4pgw0000gn/T/xfs-5a5a01ba/build.log)
I tracked down why @okta/okta-auth-js
has microtime
. It's because of broadcast-channel
:
~/okta-repro (main)> yarn why microtime
└─ broadcast-channel@npm:4.13.0
└─ microtime@npm:3.0.0 (via npm:3.0.0)
~/okta-repro (main)> yarn why broadcast-channel
└─ @okta/okta-auth-js@npm:6.7.2
└─ broadcast-channel@npm:4.13.0 (via npm:^4.13.0)
microtime
already has a fix out for this in 3.1.0
(see https://github.com/wadey/node-microtime/pull/68), but broadcast-channel
hasn't released a new version that specifies it yet, and they've disabled GitHub issues.
I'm not sure how to proceed from here. Is there a way this package could set a resolution for microtime
? Or do the maintainers of this package know how to contact the authors of broadcast-channel
? Thanks!
What is expected to happen?
The installation completes successfully.
What is the actual behavior?
The installation fails because microtime
can't be built.
Reproduction Steps?
On an M1 mac:
mkdir okta-repro
cd okta-repro
yarn init -2
yarn add @okta/okta-auth-js
# ...
➤ YN0000: ┌ Link step
➤ YN0007: │ microtime@npm:3.0.0 must be built because it never has been before or the last one failed
➤ YN0009: │ microtime@npm:3.0.0 couldn't be built successfully (exit code 1, logs can be found here: /private/var/folders/dt/yks4v5m53k114qxgz6jh4pgw0000gn/T/xfs-5a5a01ba/build.log)
➤ YN0000: └ Completed in 3s 969ms
➤ YN0000: Failed with errors in 11s 119ms
SDK Versions
~/okta-repro (main)> yarn why microtime
└─ broadcast-channel@npm:4.13.0
└─ microtime@npm:3.0.0 (via npm:3.0.0)
~/okta-repro (main)> yarn why broadcast-channel
└─ @okta/okta-auth-js@npm:6.7.2
└─ broadcast-channel@npm:4.13.0 (via npm:^4.13.0)
Execution Environment
On an M1 mac:
System:
OS: macOS 12.3.1
Shell: 5.8 - /bin/zsh
Binaries:
Node: 16.15.1 - /private/var/folders/dt/yks4v5m53k114qxgz6jh4pgw0000gn/T/xfs-ce2eccbb/node
Yarn: 3.2.1 - /private/var/folders/dt/yks4v5m53k114qxgz6jh4pgw0000gn/T/xfs-ce2eccbb/yarn
Additional Information?
No response
Thanks for submitting this issue. Internal ref: OKTA-516169
As a work around you can try specifying
"resolutions": {
"microtime": "^3.1.0"
},
in your package.json
@jaredperreault-okta thanks! That does work, but it's something that users have to do in their project. (We could write a codemod to parse their package.json
and add that resolution for them, but that's a lot of work. 😅)
More importantly, many users forget to remove that resolution after the problem has been resolved, so they're pinned to it. (We could also write a codemod or add middleware to our CLI that does a background check, telling them they're all good to remove it now cause there's a new version, but that's even more work.)
@jtoar yes, using resolutions
is just a work around to unblock your development while we work on a fix.
To provide an update on this:
Our dependency, broadcast-channel
released version 4.14.0
which bumps the microtime
dependency to 3.1.0
. [email protected]
fixes this m1 mac build issue, however it also requires a minimum node version of 14+. We consider raising the minimum node version to be a breaking change, and therefore this fix will have to wait until our next major version (7.x
) release.
Until then I suggest using the resolutions
work around described above, assuming you're already on node 14+
Thank you for the update! The current version of this package lists broadcast-channel
using the SemVer ^
range specifier, which looks for the latest minor, so 4.14 will actually be installed now (which may not be exactly what you want for the reasons mentioned). That means this issue is solved for us now.
@jtoar FYI this issue should be fixed as of 6.8.1
. broadcast-channel
accepted our PR to remove microtime
as a dependency and we now depend on ~4.17.0
(which includes our PR)