Remix "Eurodance Stack" aka "Enka Stack" aka Vulcan Remix

[eric-burel]

🇪🇺 🐸 🛵

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

• Fix the websocket error fix(remix-dev): re-use REMIX_DEV_SERVER_WS_PORT when reloading config remix-run/remix#3206
• Get rid of the SSR mismatch when browser extensions are installed
• Make it possible to run on codesandbox with DATABASE_URL not set https://discord.com/channels/770287896669978684/954545525984722954/983790925706829884

Mongo and db

• Support Mongo

GraphQL: query and mutation basics

• Setup GraphQL API consumption with "remix-graphql" https://github.com/thomasheyenbrock/remix-graphql, demo on the Rick and Morty API https://rickandmortyapi.com/documentation/
  We could investigate a more generic solution like graphql-client described in this article from GraphCMS
• 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

• 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
• 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
• Setup MSW or mocking for data fetching + loader functions: 🗺️ Storybook + Testing Helper remix-run/remix#2481
• Remove the override needed for React 18 support with mdx MDX2: Can't resolve '@mdx-js/react' storybookjs/storybook#18094

Still have some cache issues, yarn start-storybook --no-manager-cache can help if stories are not showing up

Testing

• Verify that fixtures can be shared between Cypress, unit tests, and storybook

Vercel

• Deploy on Vercel
  See https://github.com/wladiston/remix-vercel-monorepo and https://github.com/robipop22/dnb-stack => it seems to work out of the box, the dnb-stack show a few advanced settings
• We may need additional setup: https://vercel.com/docs/build-output-api/v3 and Update Indie stack to work with Vercel remix-run/remix#2660 and https://remix.run/docs/en/v1/api/conventions#serverbuildtarget
• Documented the missing SESSION_SECRET variable and how to create it with Vercel CLI
• Need to figure out Prisma DATABASE_URL: how to make it optional on pages that don't use the db?
• We use the deprecated File System API v2, we need to dig how to update the v3 build API: https://vercel.com/docs/file-system-api/v2
• Automatically generate a unique "vercel.json" during init step? to avoid deploying to the same name?
• It seems to be possible to pick Vercel when creating a new Remix app via CLI, we should document that for users that just want Vercel but not the rest of the stack https://vercel.com/guides/deploying-remix-with-vercel and https://remix.run/docs/en/v1/guides/deployment

Yarn 3 workspaces

• basic Setup in the monorepo
• Can detect whether we are in the monorepo or not: see .vulcan/script/is-monorepo. This will be needed to handle yarn.lock correctly.
• 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 [Bug]: Yarn 3 support? remix-run/remix#683 (comment)
  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.

See yarnpkg/berry#1223 (comment) for a possible solution with a plugin + postinstall script or yarnpkg/yarn#5428

Possible solutions:

• 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

Most promising solution: varsis/generate-lockfile#4

• 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: workspaces "bin" symlinks not created for sub-dependencies  yarnpkg/yarn#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"
• "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 features https://www.npmjs.com/package/concurrently => Remix might also update to other better maintained tools
• 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

• 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

• 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.

• https://github.com/sergiodxa/remix-i18next