OpenNeo/impress-2020
OpenNeo/impress-2020
1
0
Fork 0
Code Pull requests Activity
impress-2020/package.json

105 lines
4.5 KiB
JSON
Raw Normal View History

Initialize app with create-react-app
2020-04-21 17:49:52 -07:00
{
"name": "impress-2020-app",
"version": "0.1.0",
"private": true,
"dependencies": {
Upgrade @apollo/client to 3.3.7 So, I ran into some weird Apollo behavior, and was hoping it was a bug that the upgrade would fix. It didn't! But it seems to still run the site fine, so, okay, new version, neat! Idly wondering if it's time to start adding some basic e2e tests, to validate updates like this...
2021-01-22 14:37:06 -08:00
"@apollo/client": "^3.3.7",
got apollo server running as a vercel function!
2020-04-22 14:02:23 -07:00
"@apollographql/graphql-playground-html": "^1.6.24",
add auth0 for login Gonna need to import our folx into it, but gosh it would be nice to not be responsible for this anymore 😬
2020-09-02 03:06:09 -07:00
"@auth0/auth0-react": "^1.0.0",
Update to latest Chakra UI I found a bug, and just wanted to make sure the latest version didn't have it! So hey, update time!
2021-02-02 16:00:49 -08:00
"@chakra-ui/icons": "^1.0.4",
Upgrade Chakra, remove tooltip flicker workaround
2021-02-22 19:00:47 -08:00
"@chakra-ui/react": "^1.3.3",
Update to latest Chakra UI I found a bug, and just wanted to make sure the latest version didn't have it! So hey, update time!
2021-02-02 16:00:49 -08:00
"@chakra-ui/theme-tools": "^1.0.3",
upgrade Chakra packages
2020-12-25 09:07:59 -08:00
"@emotion/react": "^11.1.4",
"@emotion/styled": "^11.0.0",
code-split OutfitControls
2020-05-18 00:11:18 -07:00
"@loadable/component": "^5.12.0",
feedback form now sends actual emails!
2020-10-09 08:55:03 -07:00
"@sendgrid/mail": "^7.2.6",
Add Sentry error logging + privacy statement My main reason for adding this now is that I'm getting some scattered reports of things not displaying correctly, and I want to start gathering some browser data on that... I recently confirmed that animations work on iOS (at least one did!), which was going to be my guess of what was breaking...
2021-01-16 10:59:54 -08:00
"@sentry/react": "^5.30.0",
"@sentry/tracing": "^5.30.0",
Initialize app with create-react-app
2020-04-21 17:49:52 -07:00
"@testing-library/jest-dom": "^4.2.4",
"@testing-library/react": "^9.3.2",
"@testing-library/user-event": "^7.1.2",
Finally finish TS setup, build works! `yarn build` was crashing on my `build-cached-data` script, because we were trying to run the Typescript file uncompiled! Now, we run it with `ts-node`, which transparently compiles Typescript files before execution. Phew! `react-scripts build` made some automated changes to `tsconfig.json` for compatibility with `create-react-app`, and I also added a `ts-node` section to override one of them so we can compile to CommonJS for `ts-node` script execution!
2021-02-02 21:38:57 -08:00
"@types/node": "^14.14.22",
"@types/react": "^17.0.1",
"@types/react-dom": "^17.0.0",
http caching for all color/species requests
2020-05-14 15:51:08 -07:00
"apollo-link-persisted-queries": "^0.2.2",
Add stale-while-revalidate cache headers Oh yay, I'm pleased with this! I hope it works out well! stale-while-revalidate is an HTTP caching feature that gives us the ability to still serve relatively static content like item pages ASAP, while also making sure users generally see updates quickly. The trick is that we declare a period of time where, you can still serve the data from the cache, but you should _then_ go re-fetch the latest data in the background for next time. This works on end users and on the CDN! I've scanned the basic wardrobe and homepage stuff and brought them up-to-date, and gave particular attention to the item page, which I hope can be very very snappy now! :3 Note to self: Vercel says we can manually clear out a stale-while-revalidate resource by requesting it with `Pragma: no-cache`. I'm not sure it will listen to us for _fresh_ resources, though, so I'm not sure we can actually use that to flush things out in the way I had been hoping until writing this sentence lol :p
2021-02-02 19:07:38 -08:00
"apollo-server": "^2.19.2",
"apollo-server-core": "^2.19.2",
"apollo-server-env": "^3.0.0",
Finish support tool to upload manual PNGs Great for fixing those ones that the auto converters can't do!
2020-08-04 18:39:31 -07:00
"aws-sdk": "^2.726.0",
outfit-images: use node-canvas to render image
2021-01-03 20:16:48 -08:00
"canvas": "^2.6.1",
move to vercel now function api structure I haven't really tested the API yet, because it's hard to query GraphQL directly, but I'll set up the client in a bit for it!
2020-04-22 13:03:32 -07:00
"dataloader": "^2.0.0",
add descriptions to closet lists (formatted! :3)
2020-10-28 00:00:14 -07:00
"dompurify": "^2.2.0",
upgrade Chakra packages
2020-12-25 09:07:59 -08:00
"framer-motion": "^3.1.1",
Add stale-while-revalidate cache headers Oh yay, I'm pleased with this! I hope it works out well! stale-while-revalidate is an HTTP caching feature that gives us the ability to still serve relatively static content like item pages ASAP, while also making sure users generally see updates quickly. The trick is that we declare a period of time where, you can still serve the data from the cache, but you should _then_ go re-fetch the latest data in the background for next time. This works on end users and on the CDN! I've scanned the basic wardrobe and homepage stuff and brought them up-to-date, and gave particular attention to the item page, which I hope can be very very snappy now! :3 Note to self: Vercel says we can manually clear out a stale-while-revalidate resource by requesting it with `Pragma: no-cache`. I'm not sure it will listen to us for _fresh_ resources, though, so I'm not sure we can actually use that to flush things out in the way I had been hoping until writing this sentence lol :p
2021-02-02 19:07:38 -08:00
"graphql": "^15.5.0",
add Honeycomb logging This will let me see traces for stuff!
2020-08-16 23:28:41 -07:00
"honeycomb-beeline": "^2.2.0",
Bump immer from 6.0.8 to 8.0.1 Bumps [immer](https://github.com/immerjs/immer) from 6.0.8 to 8.0.1. - [Release notes](https://github.com/immerjs/immer/releases) - [Commits](https://github.com/immerjs/immer/compare/v6.0.8...v8.0.1) Signed-off-by: dependabot[bot] <support@github.com>
2021-01-20 23:31:25 -08:00
"immer": "^8.0.1",
Finish support tool to upload manual PNGs Great for fixing those ones that the auto converters can't do!
2020-08-04 18:39:31 -07:00
"jimp": "^0.14.0",
set up auth on the server + test utils
2020-09-02 23:00:16 -07:00
"jsonwebtoken": "^8.5.1",
"jwks-rsa": "^1.9.0",
LRU caches to speed up outfit layer preload The layer preloader already takes advantage of, and primes, the HTTP cache. But we still do duplicate work, on every OutfitPreview render, to re-execute movie clip libraries, and create a movie clip to test for animations. The former is nontrivial cost, and the latter is often large cost. This can make even basic outfit changes slow, when there's no change to the movie clip layers and the player is paused! Here, we add an LRU cache for movie clip libraries, and for the question of "is it animated?". This should speed up a number of places where we would reload the movie (including between toggling the item), and various changes that were triggering full movie clip rebuilds unnecessarily. We _aren't_ solving here for the fact that toggling an animated item requires rebuilding the movie clip, which could conceivably be cached—but with some state management trickiness, because ideally it should be a separate clip for each context where it's being shown. Imo not yet worth the effort! (esp because I think users understand that toggling an animated item can be slow, whereas this was affecting _other_ actions way too much)
2021-04-16 20:16:56 -07:00
"lru-cache": "^6.0.0",
move to vercel now function api structure I haven't really tested the API yet, because it's hard to query GraphQL directly, but I'll set up the client in a bit for it!
2020-04-22 13:03:32 -07:00
"mysql2": "^2.1.0",
move neopets.com loading into server the client stuff worked locally, but not in prod because you can't request http from https, even with cors set up correctly 😅
2020-04-25 06:50:34 -07:00
"node-fetch": "^2.6.0",
upgrade to React 17 Another longshot attempt to fix the prod-only emotion bug for free :p This should be a very easy upgrade, bc I don't think we depend on the minor stuff that had breaking changes.
2020-12-28 14:07:03 -08:00
"react": "^17.0.1",
WIP: search suggestions
2020-09-01 17:59:04 -07:00
"react-autosuggest": "^10.0.2",
upgrade to React 17 Another longshot attempt to fix the prod-only emotion bug for free :p This should be a very easy upgrade, bc I don't think we depend on the minor stuff that had breaking changes.
2020-12-28 14:07:03 -08:00
"react-dom": "^17.0.1",
Add disabled save UI
2021-03-29 19:46:21 -07:00
"react-icons": "^4.2.0",
basic home page!
2020-05-10 00:21:04 -07:00
"react-router-dom": "^5.1.2",
upgrade to react-scripts 4.0.1 I'm naively hoping that this fixes the issue with Emotion/Chakra styles that only shows up on prod… We've had an issue with prod-only bugs before, and it was due to a compiler bug re comments in JSX. I'm wondering if maybe one of our deps now has the same or a similar bug? and if maybe upgrading react-scripts will upgrade webpack, which might fix it? It's a bit of a longshot, but it's a good upgrade to do anyway, so let's see if we get lucky! Also, react-scripts 4 has Fast Refresh built in, so we can remove our overrides that added it!
2020-12-28 13:47:09 -08:00
"react-scripts": "^4.0.1",
use xmlrpc to load pets, not json.php The AMFPHP gateway's json.php endpoint has always had a problem parsing pets whose names start with digits… I've dug into it before, and checked again today, and there really is just no way around it: https://github.com/silexlabs/amfphp-1.9/blob/d584b58e9581ecbd72def15d1fd31eb2408d050f/core/json/app/Actions.php#L43 And there aren't any reliable AMFPHP Node libraries out there to make the actual native AMF call. Buuuut! In today's investigation, I noticed the xmlrpc.php endpoint for the first time. And, wouldn't you know it, there's //great// reliability for something as enterprise-standard as that! So here, I've switched over to using an xmlrpc client library, which simplifies our calling code //and// makes number pets work correctly 😁 I wouldn't have done it just for the simplification, I think bringing in a library is net more complexity… but getting this finally right is a big relief.
2020-10-22 23:22:04 -07:00
"react-transition-group": "^4.3.0",
add descriptions to closet lists (formatted! :3)
2020-10-28 00:00:14 -07:00
"simple-markdown": "^0.7.2",
Finally finish TS setup, build works! `yarn build` was crashing on my `build-cached-data` script, because we were trying to run the Typescript file uncompiled! Now, we run it with `ts-node`, which transparently compiles Typescript files before execution. Phew! `react-scripts build` made some automated changes to `tsconfig.json` for compatibility with `create-react-app`, and I also added a `ts-node` section to override one of them so we can compile to CommonJS for `ts-node` script execution!
2021-02-02 21:38:57 -08:00
"typescript": "^4.1.3",
use xmlrpc to load pets, not json.php The AMFPHP gateway's json.php endpoint has always had a problem parsing pets whose names start with digits… I've dug into it before, and checked again today, and there really is just no way around it: https://github.com/silexlabs/amfphp-1.9/blob/d584b58e9581ecbd72def15d1fd31eb2408d050f/core/json/app/Actions.php#L43 And there aren't any reliable AMFPHP Node libraries out there to make the actual native AMF call. Buuuut! In today's investigation, I noticed the xmlrpc.php endpoint for the first time. And, wouldn't you know it, there's //great// reliability for something as enterprise-standard as that! So here, I've switched over to using an xmlrpc client library, which simplifies our calling code //and// makes number pets work correctly 😁 I wouldn't have done it just for the simplification, I think bringing in a library is net more complexity… but getting this finally right is a big relief.
2020-10-22 23:22:04 -07:00
"xmlrpc": "^1.3.2"
Initialize app with create-react-app
2020-04-21 17:49:52 -07:00
},
"scripts": {
Oh, actually add TS_NODE_COMPILER to yarn start! I wrote about this in the commit message, but forgot to do it!
2021-02-07 00:23:19 -08:00
"start": "TS_NODE_COMPILER=typescript-cached-transpile vercel dev",
Fix dev command for TS support Gosh, I'm really down this rabbit hole, huh? :p Anyway, turns out the `vercel dev` command contains a _fork_ of ts-node that doesn't respect the `ts-node` override key in `tsconfig.json`. But it does respect the env var! So I've now set up `yarn start` to invoke `vercel dev` with the new env, which in turn invokes `yarn dev` to start the create-react-app dev server. Whew! (Probably a better dev experience tbh.)
2021-02-02 22:25:54 -08:00
"dev": "yarn build-cached-data && REACT_APP_IMPRESS_LOG_IN_AS=$IMPRESS_LOG_IN_AS react-scripts start",
upgrade to react-scripts 4.0.1 I'm naively hoping that this fixes the issue with Emotion/Chakra styles that only shows up on prod… We've had an issue with prod-only bugs before, and it was due to a compiler bug re comments in JSX. I'm wondering if maybe one of our deps now has the same or a similar bug? and if maybe upgrading react-scripts will upgrade webpack, which might fix it? It's a bit of a longshot, but it's a good upgrade to do anyway, so let's see if we get lucky! Also, react-scripts 4 has Fast Refresh built in, so we can remove our overrides that added it!
2020-12-28 13:47:09 -08:00
"build": "yarn build-cached-data && react-scripts build",
outfit-images: fix prod-only bugs We needed an extra build step to get node-canvas working! And `setHeader` is fluent in dev, but not in prod? Go figure!
2021-01-03 22:58:09 -08:00
"vercel-build": "yum install libuuid-devel libmount-devel && cp /lib64/{libuuid,libmount,libblkid}.so.1 node_modules/canvas/build/Release/",
outfit-images: placeholder function and test!
2021-01-03 19:57:02 -08:00
"test": "react-scripts test --env=jsdom",
Install Cypress for e2e testing It's my first time using it, but it feels great already, I'm excited! Getting it set up in WSL OpenSUSE was a bit tricky, but we got there! Had to install a lot of deps, a font package, and add some basic config to ~/.bashrc. This guide gave us most of it, but we had to do a couple other little things, too! None of them were too nasty though, just some Googling and trying things. https://nickymeuleman.netlify.app/blog/gui-on-wsl2-cypress
2021-02-04 22:19:10 -08:00
"cypress": "cypress open",
add GQL support for appearance data!
2020-04-23 01:08:00 -07:00
"eject": "react-scripts eject",
add a convenient `yarn mysql-admin` just for me I use this as an easy shortcut to log into the prod database, with credentials that have more permissions than the app currently does 😅
2020-08-11 22:07:56 -07:00
"mysql": "mysql --host=impress.openneo.net --user=$(dotenv -p IMPRESS_MYSQL_USER) --password=$(dotenv -p IMPRESS_MYSQL_PASSWORD) --database=openneo_impress",
start setting up a local dev database
2020-09-18 05:24:03 -07:00
"mysql-dev": "mysql --host=localhost --user=impress_2020_dev --password=impress_2020_dev --database=impress_2020_dev",
create cache-asset-manifests script Just gonna bulk load all those manifests into the db, and then that should make most loads notably faster by removing the net request! 🤞 We'll still load manifests inline sometimes, but only the first time anyone pulls up the layer in impress-2020. After that, it should be cached forever!
2020-08-17 18:23:39 -07:00
"mysql-admin": "mysql --host=impress.openneo.net --user=matchu --password --database=openneo_impress",
start setting up a local dev database
2020-09-18 05:24:03 -07:00
"mysqldump": "mysqldump --host=impress.openneo.net --user=$(dotenv -p IMPRESS_MYSQL_USER) --password=$(dotenv -p IMPRESS_MYSQL_PASSWORD) --column-statistics=0",
add closet_lists to dev schema too
2020-10-22 20:32:02 -07:00
"download-mysql-schema": "yarn --silent mysqldump --no-data openneo_impress closet_hangers closet_lists items item_translations modeling_logs parents_swf_assets pet_types pet_states swf_assets users | sed 's/ AUTO_INCREMENT=[0-9]*//g' > scripts/setup-mysql-dev-schema.sql && yarn --silent mysqldump openneo_impress species species_translations colors color_translations zones zone_translations > scripts/setup-mysql-dev-constants.sql",
start setting up a local dev database
2020-09-18 05:24:03 -07:00
"setup-mysql": "yarn mysql-admin < scripts/setup-mysql.sql",
"setup-mysql-dev": "yarn mysql-dev < scripts/setup-mysql-dev-constants.sql && yarn mysql-dev < scripts/setup-mysql-dev-schema.sql",
Use typescript-cached-transpile I have this in the scripts, but the dev command is the big deal: it saves me ~2sec locally per GraphQL request :3 But the dev command requires an upstream change, I have a local fork working with it, but I'm gonna try to get a PR upstream!
2021-02-07 00:08:21 -08:00
"build-cached-data": "ts-node --compiler=typescript-cached-transpile --transpile-only -r dotenv/config scripts/build-cached-data.js",
"cache-asset-manifests": "ts-node --compiler=typescript-cached-transpile --transpile-only -r dotenv/config scripts/cache-asset-manifests.js",
delete-user.js script I already had a script for this lying around, and adapted it a tiny bit to the repository! Part of me thought about building it in as a support tool. I might've if: - this CLI didn't already exist - we already had tighter permissioning, this is pretty high stakes!!
2021-03-10 05:19:51 -08:00
"delete-user": "ts-node --compiler=typescript-cached-transpile --transpile-only -r dotenv/config scripts/delete-user.js",
Use typescript-cached-transpile I have this in the scripts, but the dev command is the big deal: it saves me ~2sec locally per GraphQL request :3 But the dev command requires an upstream change, I have a local fork working with it, but I'm gonna try to get a PR upstream!
2021-02-07 00:08:21 -08:00
"export-users-to-auth0": "ts-node --compiler=typescript-cached-transpile --transpile-only -r dotenv/config scripts/export-users-to-auth0.js"
Initialize app with create-react-app
2020-04-21 17:49:52 -07:00
},
"eslintConfig": {
"extends": "react-app"
},
"browserslist": {
"production": [
">0.2%",
"not dead",
"not op_mini all"
],
"development": [
"last 1 chrome version",
"last 1 firefox version",
"last 1 safari version"
]
Layout prototype, items panel
2020-04-21 20:32:53 -07:00
},
"devDependencies": {
Fix dev command for TS support Gosh, I'm really down this rabbit hole, huh? :p Anyway, turns out the `vercel dev` command contains a _fork_ of ts-node that doesn't respect the `ts-node` override key in `tsconfig.json`. But it does respect the env var! So I've now set up `yarn start` to invoke `vercel dev` with the new env, which in turn invokes `yarn dev` to start the create-react-app dev server. Whew! (Probably a better dev experience tbh.)
2021-02-02 22:25:54 -08:00
"5to6-codemod": "^1.8.0",
move to vercel now function api structure I haven't really tested the API yet, because it's hard to query GraphQL directly, but I'll set up the client in a bit for it!
2020-04-22 13:03:32 -07:00
"apollo-server-testing": "^2.12.0",
redo auth0 export script to use APIs, not JSON
2020-09-02 15:26:33 -07:00
"auth0": "^2.28.0",
Install Cypress for e2e testing It's my first time using it, but it feels great already, I'm excited! Getting it set up in WSL OpenSUSE was a bit tricky, but we got there! Had to install a lot of deps, a font package, and add some basic config to ~/.bashrc. This guide gave us most of it, but we had to do a couple other little things, too! None of them were too nasty though, just some Googling and trying things. https://nickymeuleman.netlify.app/blog/gui-on-wsl2-cypress
2021-02-04 22:19:10 -08:00
"cypress": "^6.4.0",
Basic outfit state Cypress tests
2021-04-16 03:04:39 -07:00
"cypress-plugin-snapshots": "^1.4.4",
add `yarn mysql` shortcut script!
2020-04-30 00:01:49 -07:00
"dotenv-cli": "^3.1.0",
create cache-asset-manifests script Just gonna bulk load all those manifests into the db, and then that should make most loads notably faster by removing the net request! 🤞 We'll still load manifests inline sometimes, but only the first time anyone pulls up the layer in impress-2020. After that, it should be cached forever!
2020-08-17 18:23:39 -07:00
"es6-promise-pool": "^2.5.0",
script to export users to auth0
2020-09-02 03:49:58 -07:00
"inquirer": "^7.3.3",
outfit-images: placeholder function and test!
2021-01-03 19:57:02 -08:00
"jest-image-snapshot": "^4.3.0",
enable Fast Refresh Following this guide: https://dutzi.party/react-fast-refresh/ This enables code changes in dev to appear faster and preserve state, instead of reloading the page!
2020-07-22 21:03:04 -07:00
"prettier": "^2.0.5",
Finally finish TS setup, build works! `yarn build` was crashing on my `build-cached-data` script, because we were trying to run the Typescript file uncompiled! Now, we run it with `ts-node`, which transparently compiles Typescript files before execution. Phew! `react-scripts build` made some automated changes to `tsconfig.json` for compatibility with `create-react-app`, and I also added a `ts-node` section to override one of them so we can compile to CommonJS for `ts-node` script execution!
2021-02-02 21:38:57 -08:00
"react-is": "^16.13.1",
Fix dev command for TS support Gosh, I'm really down this rabbit hole, huh? :p Anyway, turns out the `vercel dev` command contains a _fork_ of ts-node that doesn't respect the `ts-node` override key in `tsconfig.json`. But it does respect the env var! So I've now set up `yarn start` to invoke `vercel dev` with the new env, which in turn invokes `yarn dev` to start the create-react-app dev server. Whew! (Probably a better dev experience tbh.)
2021-02-02 22:25:54 -08:00
"ts-node": "^9.1.1",
Use typescript-cached-transpile I have this in the scripts, but the dev command is the big deal: it saves me ~2sec locally per GraphQL request :3 But the dev command requires an upstream change, I have a local fork working with it, but I'm gonna try to get a PR upstream!
2021-02-07 00:08:21 -08:00
"typescript-cached-transpile": "^0.0.6",
Upgrade vercel package
2021-02-06 22:45:35 -08:00
"vercel": "^21.2.3"
Initialize app with create-react-app
2020-04-21 17:49:52 -07:00
}
}
Copy permalink