[x] Demo a mutation using a distant API (SpaceX API)
[ ] Demo more mutations: update, delete, in an admin area
[ ] Demo connecting to an existing GraphQL framework like Gatsby
[ ] Investigate caching => no client-side GraphQL also means no Apollo cache. We purely rely on Remix loaders. How do they cache graphql queries? Given that they all use the same URL?
[ ] Setup a GraphQL Resource route,basic
[ ] Demo a query, a mutation using directly a schema defined within the remix app
Vulcan Fire
[ ] Setup Vulcan Fire Engine in the GraphQL Resource route
[ ] Connect to Prisma via a Vulcan connector?
GraphQL: lint, types
[ ] Setup type generation
[ ] Allow using a gql tag (= DocumentNode type) in addition to strings, check the impact on automated type generation
[ ] Demo generating types for a downloaded json schema (for instance when exporting from studio)
Storybook
[x] Setup Storybook, maybe with Vite bundler to be consistent with the use of Vitest? => works ok but had a weird bug on initial setup, to be tested again
[X] Setup @storybook/testing-react to load stories in unit tests => seems ok out of the box, not fully tested the global preview loading but seems ok
[X] Can detect whether we are in the monorepo or not: see .vulcan/script/is-monorepo. This will be needed to handle yarn.lock correctly.
[x] CI is broken. We had to remove "package-lock.json" from the starter so lerna publish works ok, yet it's required by the default github actions https://github.com/remix-run/remix/issues/683#issuecomment-1130176988
But we don't have yarn.lock either in the starter folder, otherwise it would disable hoisting.
Without either package-lock.json or yarn.lock the CI will fail, and it's problematic anyway.
disable the nice CI provided by the indie stack by renaming the folder to ".github.sample" and rename this folder on "init" script + reenable this CI in vulcan-npm repo instead
or find a way to have a "yarn.lock" in "starters/remix" without killing hoisting of local Vulcan packages (we need our remix-graphql fork)
[ ] CI is now running correctly.. but some jobs are failing :) need case by case investigations
[ ] First, I disabled hoisting in the Remix starter package.json. This way, the "remix" binary is installed at the package level to avoid any issue: https://github.com/yarnpkg/yarn/issues/4964. This doesn't affect other packages or starters. This not optimal though, we'd like to find a way to hoist but keep "remix" CLI and critical deps in the right folder.
[ ] We have a message "Missing the "remix" package. Please run npm install remix before remix setup." on postinstall => this is probably normal at this point, since we have the same issue in raw Indie stack.
[ ] The "remix init" command is only run with "create-remix"! Not on "postinstall"! So you need to run it manually when cloning the monorepo => added some info in the readme, but we must double check a clean install of "vulcan-npm". I suspect remix.init folder packages are not installed automatically either, so we need first a "cd remix.init && npm installand thenyarn run remix init`.
This init script is for instance in charge of copying ".env.example" to ".env"
[x] "yarn run dev" doesn't work, because "run-p" is probably not run at the correct level. ./node_modules/.bin/run-p dev:* does work though. Same for "yarn run build". => concurrently works better and have the same featureshttps://www.npmjs.com/package/concurrently => Remix might also update to other better maintained tools
[x] Maybe I should remove this starter from Yarn workspaces, however I am afraid this would later be problematic when importing local Vulcan packages (basically Yarn will fetch them on NPM, not link them locally)? => let's be bold and keep it in the monorepo, at the moment the build works ok
Styling
[X] Setup tailwind autocomplete => it seems to work out of the box actually
[ ] Provide basic tailwind utilities for faster startup. Tailwind is quite low level and can be frustrating for fast prototyping. A bunch of premade classNames would do the trick + autocompletion OR importing them from a package explicitely.
Interesting, tailwind helpers bootstrap like: https://versoly.com/versoly-ui
Another one: https://daisyui.com/
Others
[x] Try running on stack blitz / code sandbox / any zero install tool => cloning on CodeSandbox Projects works pretty well. It will however open the wrong service (localhost:38XXX which is probably either a devtool or Prisma), you must open 3000 manually.
i18n
Remix has a smart way of defining the translation files you might need. useMatches let's you get some metadata for all routes and subroutes, at top level. This way, you can load translations in "root.tsx" from the metadata defined in each nested route.
🇪🇺 🐸 🛵
Vulcan Remix is a Remix stack focused on GraphQL (and a few other tools such as Storybook).
https://vulcan-remix.vercel.app/
Latest release
https://github.com/VulcanJS/eurodance-stack (edgy version) https://github.com/VulcanJS/enka-stack (stable version) https://github.com/VulcanJS/vulcan-remix (alias to eurodance-stack)
Roadmap
Various dev issues
Mongo and db
GraphQL: query and mutation basics
Vulcan Fire
GraphQL: lint, types
Storybook
Still have some cache issues,
yarn start-storybook --no-manager-cachecan help if stories are not showing upTesting
Vercel
Yarn 3 workspaces
yarn.lockeither in the starter folder, otherwise it would disable hoisting. Without eitherpackage-lock.jsonoryarn.lockthe CI will fail, and it's problematic anyway.See https://github.com/yarnpkg/berry/issues/1223#issuecomment-1135624515 for a possible solution with a plugin + postinstall script or https://github.com/yarnpkg/yarn/issues/5428
Possible solutions:
Most promising solution: https://github.com/varsis/generate-lockfile/issues/4
npm install remixbeforeremix setup." on postinstall => this is probably normal at this point, since we have the same issue in raw Indie stack.remix.initfolder packages are not installed automatically either, so we need first a "cd remix.init && npm installand thenyarn run remix init`. This init script is for instance in charge of copying ".env.example" to ".env"./node_modules/.bin/run-p dev:*does work though. Same for "yarn run build". => concurrently works better and have the same features https://www.npmjs.com/package/concurrently => Remix might also update to other better maintained toolsStyling
Others
i18n
Remix has a smart way of defining the translation files you might need.
useMatcheslet's you get some metadata for all routes and subroutes, at top level. This way, you can load translations in "root.tsx" from the metadata defined in each nested route.