Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Next.js Commerce boilerplates for each provider #347

Closed
leoortizz opened this issue May 31, 2021 · 5 comments
Closed

Next.js Commerce boilerplates for each provider #347

leoortizz opened this issue May 31, 2021 · 5 comments

Comments

@leoortizz
Copy link

Everyone might need a way to start a new Next.js Commerce app with a single provider, without all the references to providers that won't be used, and also without the demo layout. Is there any solution for this on the roadmaps?

Here are some ideas as I'm not sure on how would be the best way to handle it:

  • integrate it to create-next-app or to a new CLI like create-next-commerce with a option -p [name]/--provider [name]
  • a branch for each provider. Right now there's bigcommerce and shopify branches, but I'm not sure if it's updated/being used for this purpose
  • a single repo for the Commerce framework and 'official forks' or templates for each provider
@leoortizz leoortizz changed the title Next.js Commerce boilerplates Next.js Commerce boilerplates for each provider May 31, 2021
@muhammad-saleh
Copy link

it will be great also if we can remove other unused providers without breaking anything
I'm using Shopify and I tried to remove the bigcommerce provider the build broke

@leoortizz
Copy link
Author

it will be great also if we can remove other unused providers without breaking anything
I'm using Shopify and I tried to remove the bigcommerce provider the build broke

It seems to be in progress, see #252

@leoortizz
Copy link
Author

Closing it as it's not really an issue

@mxdi9i7
Copy link

mxdi9i7 commented Aug 27, 2021

Should probably reopen and tag a contributor? because the problem has not been solved with #252, where we are still forced to keep all provider framework code when we really just need 1 provider.

@kungfu321
Copy link

I think it's big mistake and seem like not yet already for production.

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

No branches or pull requests

4 participants