Drift is a self-hostable Gist clone. It's also a major work-in-progress, but is (almost, no database yet) completely functional.
You can try a demo at https://drift.maxleiter.com. The demo is built on master but has no database, so files and accounts can be wiped at any time.
If you want to contribute, need support, or want to stay updated, you can join the IRC channel at #drift on irc.libera.chat or reach me on twitter. If you don't have an IRC client yet, you can use a webclient here.
Setup
Development
In both server and client, run yarn (if you need yarn, you can download it here.) You can run yarn dev in either / both folders to start the server and client with file watching / live reloading.
Production
Note: Drift is not yet ready for production usage and should not be used seriously until the database has been setup, which I'll get to when the server API is semi stable.
yarn build in both client/ and server/ will produce production code for the client and server respectively. The client and server each also have Dockerfiles which you can use with a docker-compose (an example compose will be provided in the near future).
If you're deploying the front-end to something like Vercel, you'll need to set the root folder to client/.
Current status
Drift is a major work in progress. Below is a (rough) list of completed and envisioned features. If you want to help address any of them, please let me know regardless of your experience and I'll be happy to assist.
creating and sharing private, public, unlisted posts
this is carryover from: https://github.com/MaxLeiter/Drift/pull/13
gets the images built and containers running for both server and client. there is a server build issue in builder because it cant find .env:
Step 13/24 : RUN yarn build
---> Running in ef5ee9eca9ee
yarn run v1.22.18
$ mkdir -p ./dist && cp .env ./dist/.env && tsc -p ./tsconfig.json && tsc-alias -p ./tsconfig.json && yarn post-build
cp: can't stat '.env': No such file or directory
error Command failed with exit code 1.
explicitly giving the image a duplicated .env.test -> .env allows the build to complete and create container. there is another issue that i ran into when loading the client at http://localhost:3001/:
Something went wrong. Is the server running?
and when navigating to: http://localhost:3001/signup
here a little improvement from my side and a quick little note regarding your auth component.
I tried to make it geist agnostic -> i do like geist but saw you want to shift away from it. The geist approach would be to use a Grid here but it is fine like that.
You explicitly check for empty spaces or a set input through regex which does not make any sense while using such a UI lib. Even if you move to chakra or material ui or any other ui lib, it is handled for you and this type of input check should be on the backend side only then. However if you'd like to make some manual checks it is fine as well but for this case it is not really useful
I would rather display a general toast regarding errors instead of printing the api response to the client, another option would be to use a Note (https://geist-ui.dev/en-us/components/note) above the login form.
I reverted the auth button to be filled initially which is a bit user friendlier ui/ux wise
feel free to make your changes and have fun on your project
Currently a new developer, with no previous configuration, would need to create a new server/.env file with a secret, matching the one in client/.env.local. This felt somewhat asymetric, so I wanted the first development experience to be the smoothes it can be.
Given that the client/ already uses a default .env.local and logs:
info - Loaded env from D:\Workspace\Drift\client\.env.local
Why shoudn't the server/?
Alternatives
Rather than having a .env.local, we could improve the first developer experience by having a default on all environment variables. Namely SECRET_KEY. But I would push for this default to be in both client/ and server/ and remove the client/.env.local.
I was pondering if server/index.ts was where I wanted to add the complexity of loading a .env.local, or in server\src\lib\config.ts. I opted for the one that I felt more idiomatic to the code base, but I'm open to discussions
The title say it all but the front-end was allowing to create a user with empty username/password (I think its worth check in backend), I did a small refactor on handle submit too.
And I created a reusable head component so we don't need to repeat some logic in every page.
Again with my awful UI 😅
I tried aligning the buttons to the right, like the UX when creating. Cound't CSS 🙈.
I tried the UX of having a ButtonDropdown but felt... off. Cant really explain.
Test are missing. I know. I started with https://github.com/MaxLeiter/Drift/issues/79 but got a bit derailed with #64 😳
Change you own post
A protected post
Seeing another user's post
Discussion point
It is weird that the links to the posts depend on the visibility. Now that we can change it, links will break.
Say I send you a link to http://drift/post/**protected**/91b769ab-b96e-4222-8501-95b0749a920e or http://drift.com/post/**private**/91b769ab-b96e-4222-8501-95b0749a920e, but then make it public; the old link will break.
I think any visibility should check the post ID and redirect accordingly to the current visibility.
The 1 is easy enough, as you can fetch the raw_url direct.
The 2 is a bit tricky, as one should clone the git repo. I was not about to make the server clone a repo to get the 301th file 😅 so I opted to simply throw. We can improve on it later 🤷
Gists to test these limits:
Big file: https://gist.github.com/jazcarate/50bb04ad4904dc42dce512c10e9e0557
Many files: https://gist.github.com/jazcarate/bf8b6ac8c82f09946e350814aa3c84a1
Creation date
I opted to import the creation date of a gist, but not the updated_at. It is a bit weird that you can import an old gist, and not see it in the /mine, but I felt it was more convenient to keep the created_at. We can make the creation date be the imported date. I don't have a good reason for either one 😸
Pending
A UI. I wanted to push this first part, discuss the endpoint, then make a bulk import (maybe a queue? so we don't overload the server. Or even push the fetching to the frontend 🤔)
Suggesting this change simply because "ZIP" appears to be (per its specification published by PKWARE) canonically spelled uppercase.
I also added the word "archive" to provide a noun modified by "ZIP" rather than treating "ZIP" as a noun itself. It seems clearer this way, but may cause text flow issues in the design if it's too long.
Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behaviour:
Try uploading a file with an extension of .go or .mod
Try uploading a large JSON
Expected behaviour
I would expect the upload to work since they are text files (and python files do work with .py). And the JSON is only 18MB, but it claims to be too large
Screenshots
❯ ls -alh not_matched_x.json
-rw-r--r--@ 1 adyah staff 18M Jan 25 18:39 not_matched_x.json
Desktop (please complete the following information):
OS: macOS
Browser Safari
Version 15.4
Additional context
Add any other context about the problem here.
[2/4] Fetching packages...
error Couldn't find match for "918052b538b0effe6c4a44c74a16b2749c08a0d2" in "refs/heads/master,refs/heads/renovate/eslint-8.x,refs/heads/renovate/mocha-9.x,refs/heads/renovate/node-gyp-9.x,refs/heads/ubuntu18,refs/tags/0.0.2,refs/tags/0.0.3,refs/tags/0.0.6,refs/tags/1.0.0,refs/tags/1.0.1,refs/tags/1.0.2,refs/tags/1.0.3,refs/tags/2.0.0,refs/tags/2.0.1,refs/tags/2.0.10,refs/tags/2.0.11,refs/tags/2.0.12,refs/tags/2.0.13,refs/tags/2.0.2,refs/tags/2.0.3,refs/tags/2.0.4,refs/tags/2.0.5,refs/tags/2.0.6,refs/tags/2.0.7,refs/tags/2.0.8,refs/tags/2.0.9,refs/tags/v2.0.14,refs/tags/v2.0.15,refs/tags/v2.0.16,refs/tags/v2.0.17,refs/tags/v2.0.18,refs/tags/v2.1.0,refs/tags/v2.1.1,refs/tags/v2.1.10,refs/tags/v2.1.11,refs/tags/v2.1.12,refs/tags/v2.1.13,refs/tags/v2.1.14,refs/tags/v2.1.15,refs/tags/v2.1.16,refs/tags/v2.1.17,refs/tags/v2.1.18,refs/tags/v2.1.19,refs/tags/v2.1.3,refs/tags/v2.1.4,refs/tags/v2.1.5,refs/tags/v2.1.7,refs/tags/v2.1.7-alpha,refs/tags/v2.1.8,refs/tags/v2.1.9,refs/tags/v2.2.0,refs/tags/v2.2.0-alpha,refs/tags/v2.2.1,refs/tags/v2.2.3,refs/tags/v2.2.4,refs/tags/v2.2.5,refs/tags/v2.2.6,refs/tags/v3.0.0,refs/tags/v3.0.1,refs/tags/v3.0.10,refs/tags/v3.0.2,refs/tags/v3.0.3,refs/tags/v3.0.4,refs/tags/v3.0.5,refs/tags/v3.0.6,refs/tags/v3.0.7,refs/tags/v3.0.8,refs/tags/v3.0.9,refs/tags/v3.1.0,refs/tags/v3.1.1,refs/tags/v3.1.10,refs/tags/v3.1.11,refs/tags/v3.1.12,refs/tags/v3.1.13,refs/tags/v3.1.2,refs/tags/v3.1.3,refs/tags/v3.1.4,refs/tags/v3.1.5,refs/tags/v3.1.6,refs/tags/v3.1.7,refs/tags/v3.1.8,refs/tags/v3.1.9,refs/tags/v4.0.0,refs/tags/v4.0.1,refs/tags/v4.0.2,refs/tags/v4.0.3,refs/tags/v4.0.5,refs/tags/v4.0.6,refs/tags/v4.0.8,refs/tags/v4.0.9,refs/tags/v4.1.0,refs/tags/v4.1.1,refs/tags/v4.2.0,refs/tags/v5.0.0,refs/tags/v5.0.1,refs/tags/v5.0.2,refs/tags/v5.0.3,refs/tags/v5.0.4,refs/tags/v5.0.5" for "https://github.com/mapbox/node-sqlite3".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
The command '/bin/sh -c yarn install' returned a non-zero code: 1
ERROR: Service 'server' failed to build : Build failed
To Reproduce
Steps to reproduce the behavior:
git clone this repo
cd Drift
edit docker-compose.yml
docker-compose up
Expected behavior
yarn install success
Desktop (please complete the following information):
[ ] the issue of image size(~2GB) due to bundling node_modules. to slim it down it would need to use the next standalone build tool: https://nextjs.org/docs/advanced-features/output-file-tracing#automatically-copying-traced-files
this needs testing with auth providers as the example is what was in the compose originally. if you run the db on the same host as drift you will need to manually make a docker network for them to communicate as the compose file cant do that for you.
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
@dependabot use these labels will set the current labels as the default for future PRs for this repo and language
@dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
@dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
@dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language
You can disable automated security fix PRs for this repo from the Security Alerts page.