Skip to content
This repository has been archived by the owner on Feb 12, 2021. It is now read-only.

Remove jwt-decode as a peerDependency #45

Open
pirelenito opened this issue Aug 2, 2017 · 19 comments
Open

Remove jwt-decode as a peerDependency #45

pirelenito opened this issue Aug 2, 2017 · 19 comments

Comments

@pirelenito
Copy link
Contributor

We should extract the component that uses it on its own package.

Wdyt @deepsweet @xaviervia ?

@pirelenito
Copy link
Contributor Author

pirelenito commented Aug 2, 2017

Another option would be to make it as a dependency (I looked and it is not that big), ship the package as ES2015 modules and let clients deal with not being bundle by simple tree-shaking.

@deepsweet
Copy link
Contributor

monorepo

@pirelenito
Copy link
Contributor Author

Yep! That is even better... mono repo the shit out of these hocs so that they are published individually.

@deepsweet
Copy link
Contributor

as an example https://github.com/deepsweet/hocs

@pirelenito
Copy link
Contributor Author

Fantastic! Should we make this happen?

@deepsweet
Copy link
Contributor

Does Sagui support it as well as multiple builds?

node_modules/@hocs/with-lifecycle
├── dist
│   ├── with-lifecycle.js
│   └── with-lifecycle.min.js
├── es
│   └── index.js
├── lib
│   └── index.js
└── package.json

@pirelenito
Copy link
Contributor Author

pirelenito commented Aug 2, 2017

But with lerna, it would be basically multiple packages, each with their own package.json \ sagui.

But given these are just libraries, we can also just use Babel and Jest directly. We don't need the webpack for anything anyway.

@deepsweet
Copy link
Contributor

Well, React itself and many ecosystem packages transpiles to dist/ folder with Webpack as well to be able to use it on JS Bin etc.

node_modules/recompose/build/
├── Recompose.js
└── Recompose.min.js

@deepsweet
Copy link
Contributor

Actually the right name for this folder is umd.

@pirelenito
Copy link
Contributor Author

Gotcha, we can do that as well.

@pirelenito
Copy link
Contributor Author

pirelenito commented Aug 2, 2017

Either way, the monorepo solution sounds like a "major" endeavor, and I need the jwt-decode fixed ASAP.

I'll prepare a first PR that simply adds it as an official dependency, and we can do the monorepo as a propper long term fix latter.

Sound good?

@deepsweet
Copy link
Contributor

Good.

pirelenito added a commit that referenced this issue Aug 2, 2017
Most people consume this library from their main entry point (`index.js`) which will make them require `jwd-decode` as a dependency. Move it to a explicit dependency for the time being since its footprint is really small.

The long term solution is to break this since package into multiple individual packages, each containing their own HOC.

#45 (comment)
pirelenito added a commit that referenced this issue Aug 2, 2017
Most people consume this library from their main entry point (`index.js`) which will make them require `jwt-decode` as a dependency. Move it to a explicit dependency for the time being since its footprint is really small.

The long term solution is to break this since package into multiple individual packages, each containing their own HOC.

#45 (comment)
@xaviervia
Copy link
Contributor

Let’s do it!

🐒repo!

(🐒 is "mono" in Spanish)

@pirelenito
Copy link
Contributor Author

pirelenito commented Aug 2, 2017

btw, https://github.com/hocs is not taken... kinda like... it is wanting for a org to rise on it!

@deepsweet
Copy link
Contributor

I registered it and then deleted 2 days ago :) Decided that mono repo should be really mono.

@xaviervia
Copy link
Contributor

But it can be a the mono repo of the org!

@xaviervia
Copy link
Contributor

Imagine that, we can have an org with a mono repo that repos all the monos!

@deepsweet
Copy link
Contributor

and there will be only one repo called hocs, so github.com/hocs/hocs. yo dawg.

@xaviervia
Copy link
Contributor

exactly

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants