ixahmedxi / orbitkit Goto Github PK

Describe the bug
I'm getting an error: 'NODE_OPTIONS' is not recognized as an internal or external command while trying to start running the project on Windows by the command pnpm turbo dev

I think that is because of NODE_OPTIONS is not supported by Windows, instead Windows uses set NODE_OPTIONS ...

Screenshots

With the release of ESLint v9, we will need to move packages/config/eslint to flat config style configuration and also remove all .eslintrc.cjs files and replace them with the modern counterparts.

The only hurdle I see to this being successful is eslint-config-next but honestly I am tempted to remove it because a lot of the useful rules aren't even working anymore, and that way the react config can be both react in general specific so we don't have a next.js and a react specific eslint configs.

https://github.com/antfu/eslint-config should be a big inspiration for this migration, not the formatting with ESLint part because we use prettier for that but the code organisation and config of that package is absolute awesome and we should learn from this and implement our new version with this as the inspiration.

As a requirement for more authentication method (for example email + verification codes authentication) orbitkit needs to have some way of sending emails, Resend and it's library, react email, seems like the best option here.

We probably should have a packages/emails that will configure resend and export the resend instance to be used in apps as well as the email templates using react email. The package should be internal as that it will be used in the web application and we can utilise transpileModules in next.config.js to avoid the build step.

Steps to work:

1. copy packages/core into new directory packages/emails
2. do your thing with adding resend and react email
3. add @orbitkit/emails to list of transpileModules in next.config.js file in apps/web
4. profit

Right now you might need to share envs with all these mono-repos

I highly recommend to use a 3rd party app that manage this, and it has CLI for that too.

https://onboardbase.com

We should create a packages/stripe package that integrates stripe functionality and let's the web application consume that to set up payment processing capabilities for the web application

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Currently, the build time for the ui package is very slow because of DTS generation of many entry points, this is a known issue with tsup and the way around it is to just increase the memory that it can use which is not great.

The options we have to tackle this are:

• move to the new experimentalDts feature, note that I have tried this and it ended up giving me a lot of TS errors.
• create our own custom packages/config/rollup where we define all bundling needs in the monorepo there.

Describe the bug
To report a security issue, we currently direct users to a 404 page.

To Reproduce
Click the open a security advisory link in SECURITY.md.

Expected behavior
The ability to report a security vulnearbility.

Additional context
Follow these docs: https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/creating-a-repository-security-advisory#creating-a-security-advisory

The README needs some work still for it to be more self explanatory and to the point, with it as wel we need a CONTRIBUTING.md file, SECURITY.md file as well and all of the markdown files docs you expect to have in an open source project.

Knip is an awesome tool that let's you know about unused deps/exports in the codebase, unused exports shouldn't be a worry of ours when it comes to the ui package but otherwise it does apply.

OrbitKit needs to also deliver github actions as part of the starterkit to help people have a solid foundation where their work is tested and checked, I have a few ideas for the kind of actions we need but here's what my mind thinks:

• Obviously the normal lint, typecheck, build, checks (turborepo)
• We need to do it so that a Neon DB branch is created for every new Pull Request, which gets consumed by the actions of that pull request and when the pull request is closed or merged, we need to run an action that will destroy that branch.
• We also need the github action to integrate with chromatic/storybook and mintlify
• I am not sure if we will need to handle vercel deployment from the github actions, because I was thinking it would actually maybe be a good idea for every pull request to have two db branches on neon, one is used for the github actions to run the e2e tests on top...etc and another one is created from the neon vercel integration for the preview deployment that way you don't get e2e test specific data into your preview deployment, further increasing accuracy between both preview and production deployment.
• We can put in templates for slack/discord messaging through the github actions maybe.

Would love to hear more thoughts about this as that I'm not the most knowledgable person when it comes to github actions.