Changes fetchye into a monorepo

[JamesSingleton]

I am opening this PR as a draft because I need to still update the documentation and workflows. However, I would like everyone to try the package(s) out.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 2b7f045:

Sandbox	Source
quick-install	Configuration
fetchye-provider-install	Configuration
fetchye-redux-provider-install	Configuration
nextjs-fetchye-ssr	Configuration

[JAdshead]

FetchyeReduxProvider needs also be its own package

[JamesSingleton]

FetchyeReduxProvider needs also be its own package

Ok perfect, I wasn't entirely sure about that.

[merceyz]

Hey @JamesSingleton 👋
Saw your tweet, what specifically is the issue with Yarn?

I cloned the repo, checked out your branch, set it to use yarn 2, added some missing dependencies, and ran the build, worked perfectly fine.

diff --git a/packages/fetchye-immutable-cache/package.json b/packages/fetchye-immutable-cache/package.json
index 160884a..f260e67 100644
--- a/packages/fetchye-immutable-cache/package.json
+++ b/packages/fetchye-immutable-cache/package.json
@@ -36,9 +36,11 @@
     "immutable": "^4.0.0-rc.12"
   },
   "devDependencies": {
+    "@babel/core": "7.11.6",
     "@rollup/plugin-babel": "^5.2.1",
     "@rollup/plugin-commonjs": "^15.1.0",
     "@rollup/plugin-node-resolve": "^9.0.0",
+    "babel-preset-amex": "^3.4.1",
     "fetchye": "*",
     "rimraf": "^3.0.2",
     "rollup": "^2.28.2",
diff --git a/packages/fetchye-redux-provider/package.json b/packages/fetchye-redux-provider/package.json
index 0683e5e..576bf25 100644
--- a/packages/fetchye-redux-provider/package.json
+++ b/packages/fetchye-redux-provider/package.json
@@ -39,10 +39,12 @@
     "redux": "^4.0.5"
   },
   "devDependencies": {
+    "@babel/core": "7.11.6",
     "@rollup/plugin-babel": "^5.2.1",
     "@rollup/plugin-commonjs": "^15.1.0",
     "@rollup/plugin-node-resolve": "^9.0.0",
     "@testing-library/react": "^11.0.4",
+    "babel-preset-amex": "^3.4.1",
     "fetchye": "*",
     "rimraf": "^3.0.2",
     "rollup": "^2.29.0",
diff --git a/packages/fetchye/package.json b/packages/fetchye/package.json
index 8a4205f..17ddda7 100644
--- a/packages/fetchye/package.json
+++ b/packages/fetchye/package.json
@@ -59,11 +59,13 @@
     "react-dom": "^16.13.1"
   },
   "devDependencies": {
+    "@babel/core": "7.11.6",
     "@babel/plugin-transform-runtime": "^7.11.5",
     "@rollup/plugin-babel": "^5.2.1",
     "@rollup/plugin-commonjs": "^15.1.0",
     "@rollup/plugin-node-resolve": "^9.0.0",
     "@testing-library/react": "^11.0.4",
+    "babel-preset-amex": "^3.4.1",
     "react": "^16.13.1",
     "react-dom": "^16.13.1",
     "react-redux": "^7.2.1",

[JamesSingleton]

@merceyz this is using Yarn 1. The issue currently is having to disable import/no-unresolved for fetchye-redux-provider and fetchye-immutable-cache

[merceyz]

I'm aware, but it's way easier to test with V2 as its node_modules linker is more stable, but I digress.

The issue you're seeing is with the eslint plugin, not yarn.
import-js/eslint-plugin-import#1174
import-js/eslint-plugin-import#1650

[JamesSingleton]

@merceyz good to know! For some reason I thought it was Yarn not resolving. Also, any particular reason for adding @babel/core directly even though babel-preset-amex brings in @babel/core?

[merceyz]

Also, any particular reason for adding @babel/core directly even though babel-preset-amex brings in @babel/core?

Yes, @rollup/plugin-babel has a peer dependency on @babel/core and it is not satisfied by babel-preset-amex. It Just Works™ because of hoisting but is really fragile, read https://yarnpkg.com/advanced/rulebook#packages-should-only-ever-require-what-they-formally-list-in-their-dependencies for a more in depth explanation.

I opened #16 (which targets this branch) to "show" the use of V2, you can close it if you want, but I highly suggest using it as its node_modules linker is more stable than V1, and makes it just a flip of a switch to adopt PnP in the future (https://yarnpkg.com/features/pnp).

You can run with PnP on the CI to catch dependency issues and node_modules locally to preserve the DX

[merceyz]

Don't think lockfile-lint is needed, the lockfile doesn't store the URL and it will only fetch from the registry specified in .yarnrc.yml

[JamesSingleton]

Don't think lockfile-lint is needed, the lockfile doesn't store the URL and it will only fetch from the registry specified in .yarnrc.yml

@merceyz so does that mean dependencies with Yarn 2 can't be hijacked in the same manner as Yarn 1 or a package-lock.json?

[merceyz]

It might be possible, but it's harder, for example all http traffic is blocked by default.

https://yarnpkg.com/configuration/yarnrc#unsafeHttpWhitelist
yarnpkg/berry#416

[merceyz]

Don't think lockfile-lint is needed, the lockfile doesn't store the URL and it will only fetch from the registry specified in .yarnrc.yml

@merceyz so does that mean dependencies with Yarn 2 can't be hijacked in the same manner as Yarn 1 or a package-lock.json?

Yarn will support blocking network requests on a per hostname basis with yarnpkg/berry#2030, that should hopefully cover the "hijack" concerns

[JAdshead]

this should probably lib

[JamesSingleton]

I mean it can technically be anything

[JAdshead]

we probably only need a CJS build for this as its a test lib

[JAdshead]

we will need to fast followup with fixes to the builds