Where is @vulcan/multi-env-demo? - Githubissues

VulcanJS / vulcan-next

The Next starter for GraphQL developers

http://vulcan-docs.vercel.app

MIT License

393 stars 29 forks source link

Where is @vulcan/multi-env-demo? #6

Closed kevinashworth closed 4 years ago

kevinashworth commented 4 years ago

Trying this package, want to learn, want to help. But after git clone and yarn install and then yarn dev with Vulcan running in another project, I get this error: Cannot find module '@vulcan/multi-env-demo'. I can't find that package here or in the main Vulcan repo.

eric-burel commented 4 years ago

This repo is veeeeery experimental. It is limited to our first experiment with packages that contains both client and server code, which is a Meteor specificity that do not really exist in the Meteor ecosystem.

You should checkout https://github.com/VulcanJS/vulcan-npm, that's where the logic will live.

Basically you will have:

the NPM package, corresponding to current Vulcan packages
A Meteor starter (Vulcan Starter + bindings between NPM packages and Meteor + some existing packages that only makes sense for Meteor)
A Next js starter

The multi-env idea will probably dropped, as it's doomed to failure (text editor can't differentiate environment so that messes up autocompletion). I'll also refactor this whole repo to include a more complete setup.

eric-burel commented 4 years ago

Ok Multi-env is actually included here. @comus did a test with a webpack setup that allows us to develop the NPM package directly here, in the Next startup, without needing to use npm link for a second NPM repo.

https://github.com/VulcanJS/vulcan-next-starter/tree/devel/packages/%40vulcan/multi-env-demo

Maybe the repo is just broken, sorry. I'll work on that in the months to come, I am currently gathering more knowledge on Next beforehand.

eric-burel commented 4 years ago

Webpack should transform "@vulcan" into "./packages/vulcan"

eric-burel commented 4 years ago

At this point what can help us the most is working on Vulcan itself, mostly on code quality eg bringing in more unit tests as it will allow me to check if I break stuffs when transitionning, or just fixing bugs. Or simply getting hands on Next build system, because it is not that easy to setup with TypeScript. I'll try to open more precise issue in the future for potential contribs.

eric-burel commented 4 years ago

Found back what the idea was. Basically we wanted to support isomorphism, like in Meteor. When importing meteor/foobar, meteor automatically translate that to meteor/foobar/client resp. server depending on the environment.

This approach is doomed to fail. I've tried to reproduce it in Next but dropped the idea.