Leaving @hapi and making new plans #2411
Assignees
Labels
breaking changes
Change that can breaking existing code
Comments
zenglenn42
added a commit
to zenglenn42/react-tutorials
that referenced
this issue
Jul 19, 2020
update dependencies
I've been wanting to update my baseline React dev environment.
There's always a tradeoff between trendy features and stability.
I'm going with the following:
yarn 1.22.4 (over npm, pnpm, yarn2 'berry')
Rationale
---------
yarn 1.x from Facebook and Google overcame some reproducibility
and security features early-on missing from npm (yarn.lock and
dependency checksums). The overall vitality of the project looks
good with continued innovation with 2.x, though I'm not ready to
jump in on that just now. I like concept of pnpm, but don't see
enough evanglism and heft to dev effort. I'm looking for low
impedance and interesting roadmap. I see more leadership on the
yarn side (e.g., workspaces, resolutions, peerDependenciesMeta,
plus all the 2.x stuff I'll embrace eventually).
typescript
Rationale
---------
As I learn more react, I see the cool kids are into typescript or
similar js enhancements. Some odd unmet dependency issues I had
while struggling with npm/cra(js) just don't happen for yarn/cra(ts)
adopters because the cra devs are baselining off of yar/cra(ts).
prettier, eslint
Rationale
---------
Code formatting and code quality are just expected these days
for any serious development effort that hopes to scale.
I took a few days to get context on how these tools are configured
and integrated to dev and ci workflows. But this exposed the
unmet peer dependency hell to which npm/node_modules are prone.
I'm mostly back from that diversion and am leveraging some of
Michał Wrzosek's fu:
https://medium.com/@xfor/setting-up-your-create-react-app-project-with-typescript-vscode-d83a3728b45e
I may leverage some of Brittney Postma's dev setup on a second pass:
https://dev.to/bdesigned/vscode-setup-with-eslint-and-prettier-1gek
since she includes eslint-config-airbnb integration of some other
vscode goodies.
--------------------------------------------------------------------
fix 7 install warnings from create-react-app (3.4.1) with resolution overrides in package.json
Seeing the following after bootstrapping from create-react-app (with typescript):
% rm yarn.lock
% rm -rf node_modules
% yarn install
-----------------------------------------
yarn install v1.22.4
info No lockfile found.
[1/5] 🔍 Validating package.json...
[2/5] 🔍 Resolving packages...
warning react-scripts > webpack-dev-server > chokidar@2.1.8: Chokidar 2 will break on node v14+. Upgrade to chokidar 3 with 15x less dependencies.
warning react-scripts > webpack-dev-server > chokidar > fsevents@1.2.13: fsevents 1 will break on node v14+ and could be using insecure binaries. Upgrade to fsevents 2.
warning react-scripts > babel-jest > @jest/transform > jest-haste-map > fsevents@1.2.13: fsevents 1 will break on node v14+ and could be using insecure binaries. Upgrade to fsevents 2.
warning react-scripts > resolve-url-loader > rework > css > source-map-resolve > urix@0.1.0: Please see https://github.com/lydell/urix#deprecated
warning react-scripts > resolve-url-loader > rework > css > source-map-resolve > resolve-url@0.2.1: https://github.com/lydell/resolve-url#deprecated
warning react-scripts > webpack > watchpack > watchpack-chokidar2 > chokidar@2.1.8: Chokidar 2 will break on node v14+. Upgrade to chokidar 3 with 15x less dependencies.
warning react-scripts > workbox-webpack-plugin > workbox-build > strip-comments > babel-plugin-transform-object-rest-spread > babel-runtime > core-js@2.6.11:
core-js@<3 is no longer maintained and not recommended for usage due to the number of issues. Please, upgrade your dependencies to the actual version of core-js@3.
-----------------------------------------
These are transitive downlevel dependencies.
Adding these version overrides in package.json seems to help without without cratering my app :-).
"resolutions": {
"**/core-js": "^3.5.0",
"**/eslint": "^6.6.0",
"**/strip-comments": "^2.0.1",
"**/chokidar": "^3.4.1",
"**/fsevents": "^2.x",
"**/source-map-resolve": "^0.6.0"
}
Here's how yarn.lock is impacted ... downlevel stuff gets aliased to uplevel packages:
core-js@^2.6.10, core-js@^3.5.0:
version "3.6.5"
resolved "https://registry.yarnpkg.com/core-js/-/core-js-3.6.5.tgz#7395dc273af37fb2e50e9bd3d9fe841285231d1a"
integrity sha512-vZVEEwZoIsI+vPEuoF9Iqf5H7/M3eeQqWlQnYa8FSKKePuYTf5MWnxb5SDAzCa60b3JBRS5g9b+Dq7b1y/RCrA==
strip-comments@^1.0.2, strip-comments@^2.0.1:
version "2.0.1"
resolved "https://registry.yarnpkg.com/strip-comments/-/strip-comments-2.0.1.tgz#4ad11c3fbcac177a67a40ac224ca339ca1c1ba9b"
integrity sha512-ZprKx+bBLXv067WTCALv8SSz5l2+XhpYCsVtSqlMnkAXMWDq+/ekVbl1ghqP9rUHTzv6sm/DwCOiYutU/yp1fw==
chokidar@^2.1.8, chokidar@^3.3.0, chokidar@^3.4.0, chokidar@^3.4.1:
version "3.4.1"
resolved "https://registry.yarnpkg.com/chokidar/-/chokidar-3.4.1.tgz#e905bdecf10eaa0a0b1db0c664481cc4cbc22ba1"
integrity sha512-TQTJyr2stihpC4Sya9hs2Xh+O2wf+igjL36Y75xx2WdHuiICcn/XJza46Jwt0eT5hVpQOzo3FpY3cj3RVYLX0g==
fsevents@2.1.2, fsevents@^1.2.7, fsevents@^2.x, fsevents@~2.1.2:
version "2.1.3"
resolved "https://registry.yarnpkg.com/fsevents/-/fsevents-2.1.3.tgz#fb738703ae8d2f9fe900c33836ddebee8b97f23e"
integrity sha512-Auw9a4AxqWpa9GUfj370BMPzzyncfBABW8Mab7BGWBYDj4Isgq+cDKtx0i6u9jcX9pQDnswsaaOTgTmA5pEjuQ==
source-map-resolve@^0.5.0, source-map-resolve@^0.5.2, source-map-resolve@^0.6.0:
version "0.6.0"
resolved "https://registry.yarnpkg.com/source-map-resolve/-/source-map-resolve-0.6.0.tgz#3d9df87e236b53f16d01e58150fc7711138e5ed2"
integrity sha512-KXBr9d/fO/bWo97NXsPIAW1bFSBOuCnjbNTBMO7N59hsv5i9yzRDfcYwwt0l04+VqnKC+EwzvJZIP/qkuMgR/w==
You'll notice I enforce that eslint /remain/ at 6.x for now.
I've been messing with my dev workflow and following guidance for automated code formatting and style auditing
which had the side effect of upgrading my eslint to 7.x., causing more yarn install warnings.
I still see /other/ warnings which I don't want to mess with for now since they seem less trivial
or relate to deprecated packages for which there is no recommended replacement:
% yarn install
yarn install v1.22.4
info No lockfile found.
[1/5] 🔍 Validating package.json...
[2/5] 🔍 Resolving packages...
warning react-scripts > jest-environment-jsdom-fourteen > jsdom > request@2.88.2: request has been deprecated, see request/request#3142
warning react-scripts > resolve-url-loader > rework > css > urix@0.1.0: Please see https://github.com/lydell/urix#deprecated
warning react-scripts > workbox-webpack-plugin > workbox-build > @hapi/joi@15.1.1: joi is leaving the @Hapi organization and moving back to 'joi' (hapijs/joi#2411)
warning react-scripts > jest > jest-cli > jest-config > jest-environment-jsdom > jsdom > request@2.88.2: request has been deprecated, see request/request#3142
warning react-scripts > workbox-webpack-plugin > workbox-build > @hapi/joi > @hapi/bourne@1.3.2: This version has been deprecated and is no longer supported or maintained
warning react-scripts > workbox-webpack-plugin > workbox-build > @hapi/joi > @hapi/hoek@8.5.1: This version has been deprecated and is no longer supported or maintained
warning react-scripts > jest > jest-cli > jest-config > jest-environment-jsdom > jsdom > left-pad@1.3.0: use String.prototype.padStart()
warning react-scripts > workbox-webpack-plugin > workbox-build > @hapi/joi > @hapi/address@2.1.4: This version has been deprecated and is no longer supported or maintained
warning react-scripts > workbox-webpack-plugin > workbox-build > @hapi/joi > @hapi/topo@3.1.6: This version has been deprecated and is no longer supported or maintained
warning react-scripts > workbox-webpack-plugin > workbox-build > @hapi/joi > @hapi/topo > @hapi/hoek@8.5.1: This version has been deprecated and is no longer supported or maintained
--------------------------------------------------------------------
upgrade recharts from 1.x to 2.x
recharts 1.8.5 is 9 months old and has a dependency upon an deprecated package:
core-js 2.x
core-js@<3 is no longer maintained and not recommended for usage due to the number of issues.
Please, upgrade your dependencies to the actual version of core-js@3.
For this reason, I intrepidly enforce a packaging upgrade from:
core-js 2.x --to--> core-js 3.x
in package.json ... and then hold my breath since major version changes
imply breaking behavior.
In fact I encounter a build break along these lines:
https://stackoverflow.com/questions/55308769/module-not-found-error-cant-resolve-core-js-es6
core-js 2.x import 'core-js/es6/math' :-( // fails
core-js 3.x import 'core-js/es/math' :-)
--
I could be more surgical with package.json and allow both 2.x and 3.x to live in my
node_modules tree, but then I'd be back to deprecation warnings.
I find an uplevel version of recharts (2.0.0-beta.6) that depends on core-js 3.x.
I'm reasonably okay with the trade off deprecated package for beta package. The beta is
on the right side of history and I only use this package sparingly
(Sistilli material-ui templates). It seems to work fine for this light weight app.
puncleV
added a commit
to puncleV/enjoi
that referenced
this issue
Jul 21, 2020
10 tasks
rentzsch
added a commit
to rentzsch/express-validation
that referenced
this issue
Jul 22, 2020
|
@hueniverse I haven't seen anything about |
|
@ZigaStrgar it came over along with Joi: https://github.com/sideway/joi-date |
|
Can't agree with the logic here, forking But if I read it right, and the plan is merely to merge your changes with hapi's fork, then you now officially have third party dependencies. Don't get me wrong, I'm not complaining; I'm merely saying that your logic is off and to me, then this marks the beginning of Hapi's end of "no external dependencies" promise. |
|
There is no plan for a fork of joi. hapi is going to use a much smaller subset that is only used internally in hapi for validating API inputs, Since hapi v19, joi is no longer exposed as a public interface. You have to register your own version of a validator which can be joi or other modules. |
|
@fjeddy I think the confusion comes from the fact that the |
|
@WesTyler I see, but I can only find |
5 tasks
|
Are the typescript types also going to be migrated to |
|
the minified bundle size of v17 is close to 148KB, i think it's too large for browsers |
I am guessing this is not yet quite there ? |
|
Will @hapi/joi-date also get migrated away from Hapi? |
|
@toymachiner62 yes. |
Kingdutch
added a commit
to Kingdutch/analytics
that referenced
this issue
Jan 2, 2021
The leadership for HapiJS has changed and Joi has been spun out as a result to remain under the original maintainer. The new leadership seems to be fine so we should be safe to continue using Hapi without a costly migration. More info can be read in the following issues: - hapijs/joi#2411 - hapijs/hapi#4111 - hapijs/hapi#4113 @hapi/hapi 20.0.0 is a drop-in replacement for 19.x that fixes a security issue. The major version change is to reflect the new management. Release notes: hapijs/hapi#4113
6 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
TL;DR
Replace
@hapi/joiwithjoiin your package.json files and your require statement. No other changes required until joi v18 is published underjoi. Expect@hapi/joito show deprecation warnings shortly.Background
The hapi project is going through a change of leadership. I have decided to step down from maintaining all hapi modules with the exception of joi.
For additional information:
Organization Changes
The joi modules was moved on GitHub from
hapijs/joitosideway/joi. Sideway Inc. is my company which still provides some limited commercial hapi support. Sideway will continue to own and maintain joi moving forward.The npm
joimodule is being resurrected and the current v17.1.1 has been published there (identical to the version available on@hapi/joi). To keep things simple, there will not be a@sideway/joimodule on npm, just plainjoi.Relationship to hapi
joi will continue to be hapi's primary data validation solution. If you have been using
@hapi/joiuntil now, you can safely switch over. Since hapi v19, joi is no longer exposed as an external dependency. This means that you must BYO validation module and you can simply swap@hapi/joiwithjoi.I will continue to work with the new hapi leadership to ensure that future changes to joi will remain compatible with hapi.
In order for hapi to maintain its "no external dependencies" promise, hapi now has its own fork of joi called
@hapi/validatewhich is a restricted version of joi used only for internal hapi API input validations. It is not exposed and should not be used outside of hapi core.Near Future
I plan to move some of joi's internals around to decouple if further from hapi modules and dependencies. Version 17.2.0 is expected in the next few days to fix bugs and add some new features. joi will be split into smaller modules internally but will still provide the same interface under
joi.The joi documentation is going to move from https://hapi.dev to a new site and will be linked to from its current home.
Future plans
I have big plans for joi, including a new fresh focus on client side development, size, and performance. Some things to expect:
Commercial support
If you are using an older version of joi and cannot upgrade to v17, a commercially supported version is available. Please contact sales@sideway.com for details.
The text was updated successfully, but these errors were encountered: