queerviolet / bones Goto Github PK

Many of the issues on queerviolet/Bones are Fullstack-centric. This is because issues cannot be opened against forks (which Fullstack's Bones currently is). We could:

• Re-init the Fullstack copy as a standalone repo (edit: with shared commit history)
• Transfer ownership of the existing repo to Fullstack (which I guess would make this repo a fork? I've never tried this)
• Leave things as they are

Thoughts?

I got a question from a student recently about whether they could use bones out there in production, and if they should attribute us in any way. I told them to use it freely and do whatever they see fit with attribution (they decided they'd attribute us and link back, too).

We should figure out a license we can put in bones :)

redux-devtools-extension is the most reliable way I have found of making this a zero-effort win for those with the Chrome extension installed. In this case, I'd also argue that the redux logging middleware should use collapsed instead of expanded log lines — assuming it stays in at all.

Right now the APP symlink is committed to node_modules.

There doesn't seem to be any real benefit to this except to demo how you can gitignore everything in a directory except certain files. The symlink is generated in the setup script if not found, and the setup script can easily be run from a postinstall (as it now does in various Bones forks).

Moreover, having git track node_modules can be annoying, as an rm -rf node_modules during development can theoretically result in spurious commits removing the APP symlink (only for it to be added back in later, after the setup script runs).

It's a fairly trivial change but I vote on removing the included symlink and sticking to the generated symlink. I am interested in possible counter-arguments however.

In github.com/FullstackAcademy/bones there are lingering issues with GitHub OAuth.

InternalOAuthError: Failed to fetch user profile (status: 401 data: {"message":"Bad credentials","documentation_url":"https://developer.github.com/v3"})

Following a conversation begun in #12.

Please let me know if I am wrong, but I am not entirely sure we should include nodemon in the default start script as that script will be used by Heroku — which, I believe, has its own process manager. Nodemon is a dev tool and I'd argue it belongs in devDependencies. In that case, we'd use nodemon in a start:dev script or similar, which the main dev script would use (instead of start).

Usage in less automatic platforms, e.g. Digital Ocean, would then use something like pm2 to manage the server instance.

This can improve the build process by making refreshes wait for builds to recompile before serving the updated bundle. Since the bundle is compiled in memory and not written to a file (in dev mode), it is also faster to generate.

Alternatively, but probably more confusingly for students, webpack-dev-server can proxy the Bones API backend.

Hot Module Replacement is awesome but requires people write the frontend of their project in a compatible way, so I don't think we need to take this feature into account when it comes to deciding Bones's build system.

However, incorporating some form of LiveReload may be a nice touch. There isn't any one canonical way to do so, though you can see some notes / one potential approach here.

There is a race condition in the test suites — they do not wait for the db to sync before sending API requests which will ultimately hit query the db. Should add a line preventing this in a before or even better beforeEach.

Bones's custom logger middleware sends any captured errors directly to the client.

Unfortunately, there seems to be a bug — in at least some cases, this results in an empty JSON object showing up in the client side. We could omit the stack trace by doing a res.send(err.toString()), resulting in an HTML page with just the error message. If we also want the stack trace, we might have to do some more work. In any case though, it would be good to track down and understand precisely why res.send(err) results in an empty JSON response. I have a suspicion it may have to do with the default behavior for calling toJSON on an Error object, but that's just a hunch, I haven't looked into it yet.

Also, we may want to distinguish between production and development behavior here, if only for the sake of demonstrating good practices (and maybe init-time branching as a concept).

https://medium.com/webpack/webpack-2-and-beyond-40520af9067f#.s1sqjeiu0

To support front-end routing, Bones has a catch-all route which sends the index page back to the client (at which point React-Router takes over and navigates to the right component).

A downside of this is that any resources not found on the server turn into 200 responses with an index HTML body. This is confusing for students.

A clunky solution for this is to have an explicit array of client-side routes maintained on the server side, all of which send back the index page.

A better solution involves using/sharing React code server-side — possibly even with some server-side rendering (!) to show the user a correct page template before front-end code takes over. The routes component can be read in by the server and used to handle requests for client-side routes. Some research should be done to see how React-Router v4 factors into this potential solution.

Either way, this would allow genuine 404s again, leading to a more pleasant and understandable development experience.

Since the server depends on the db, when the db code changes the server should restart. Change the development script to add db to the watch list (currently only server is included).

Webpack has a number of options for tailored behavior in dev vs production. For example: cheaper (but still useful) source maps in dev mode; minifying in production; gzipping in production. More info (for v2, mind you) can be found here.

This might add complexity to what is intended to be a small scaffolding base. On the other hand, it can save configuration time and act as a representative example for those interested in implementing such distinctions.

During development of a Bones-based app, one sometimes has stale cookies logged in as a user who no longer exists in the current database. This causes the server error Cannot read property 'id' of null.

If possible, it would be good to automatically clear the session on this error, so that the developer does not have to manually delete cookies.

At Fullstack Academy, we've used Codeship successfully for many projects. However, as of this writing the free Codeship tier only permits configuration through the web UI (the pro account allows for in-repo yml configuration). One workaround is Codeship-YAML, though that requires a minimal 2-line Codeship config online plus one extra npm package.

Travis is of course one of if not the most popular CI services out there, and is based on yml configs even for the free tier. We could write an appropriate config file for Bones, which would give people the option of zero-effort Travis usage (regardless of whether Fullstack as an org switches over or not).

When people use Bones to start their own projects, they often mistakenly open project-based PRs against it. This pollutes the PR history with tons of irrelevant side information, making it hard to see the development cycle of Bones proper.

One potential strategy for heading this off at the pass would be to discourage forking of Bones for starting apps. Forking would only for Bones development or spinoffs. This would basically just be a README update.

I don't see an obvious way to enforce this distinction programmatically. FSG didn't have this issue because it was an npm package, but that made it impossible to merge upstream changes into in-progress apps — a feature which we often wished for, and which Bones does have, being a straight up repo.

http://editorconfig.org/

Adherence to certain common formatting conventions — agreed upon by the team (or dictated by a project lead) — makes it easier for contributors to code into parts of an application written by others. Having your editor switch settings automatically to match a given project makes that adherence slightly less of an imposition.

Addition of an .editorconfig will involve not only adding the file, but naturally formatting the entire project to match. As formatting is highly subjective (albeit with several mainstream approaches), this issue may apply more to certain forks of Bones than the original queerviolet/Bones, in which case we may want to close this issue with no associated commits.

See heroku/heroku-buildpack-nodejs#380 for a more detailed explanation, but to summarize: Heroku's node buildpack uses yarn to install. Yarn currently has a bug wherein it doesn't do a proper integrity check as part of installation. As a result, if a devDep is changed to a dep by manually altering package.json, the deploy will mistakenly think it is still up to date, and anything relying on that dep will fail.

We can mitigate this temporarily (until yarn is fixed or the Heroku node buildpack implements a workaround) by disabling caching of the node_modules:

heroku config:set NODE_MODULES_CACHE=false

Thankfully this should still be faster than a vanilla npm install, as the yarn cache (not node_modules cache) will still be used.

I'm not sure if I want to bake this into the README at this point. I am hoping rather that the underlying issue can be fixed soon. Accordingly I'm not (yet) making a PR to change the deployment instructions.

node_modules/APP never get's created.

running Heroku run bash and entering the remote command line where on the root we ran node bin/mkapplink.js seemed to make the intended use of APP work.

Part of the issue is __dirname may be run from the incorrect path during the heroku install.

Bones currently has no specific support for styling. Leaving it like this makes it un-opinionated, but it might be nice for students to see a basic SASS compilation setup with Webpack, so they see how bundling can handle more than just JS (and so the build step doesn't fragment into multiple scripts).

@joedotjs you expressed interest in this.

There is a race condition in the server start; it listens on a port without waiting for the database to finish syncing. While this almost certainly will not cause any problems in practice (how often does a request come in during the interval between starting the server and the db syncing?), it will be easy enough to implement the fix and demonstrate good practices.

Similar to #18, following a shared code style arguably tends to result in less context switching, friction, feelings of code ownership which discourage multi-author editing, etc.

A number of good ESLint configs such as AirBnB, Standard, and Prettier exist. At Fullstack we often recommend the use of eslint-config-fullstack as a purpose-built config for students working with Node, Express, Sequelize, React, and Redux.

Students collaborating on a project may, however, have different override rules applied according to their taste. Bones could ship with the Fullstack config, ESLint, and related peer deps as dev dependencies, making linting project-based. A root eslint config in Bones would then serve as a place for teammates to agree upon shared rule overrides (or even opt into an entirely different config).

Also like #18, this addition would mean not only adding the linter and config, but reformatting the entirety of Bones to match. Accordingly, this issue may or may not apply to the original queerviolet/Bones, but rather certain forks (which cannot receive their own issues — yay GitHub).

Ran into this issue when deploying a bones app to heroku. The npm start script uses nodemon, but nodemon is not listed in any of the npm dependencies, so bones is essentially assuming that nodemon is installed globally. If you don't install it locally, your npm start script will hit errors when deployed to heroku.

Some of the debug calls are namespaced with the app name, e.g. my-cool-app:boot and my-cool-app:auth. Others are just top-level loggers, e.g. oauth and sql. We should namespace all debug calls so that all debugging info can be easily switched on with DEBUG=my-cool-app:*. Note this is more selective than DEBUG=*, which includes thousands of lines of debug code from dependencies e.g. Babel.

Hi! I have been trying to achieve the production build before deploying on Heroku. I have this React Chrome extension that tells me whether a website is using the production build or development build of React. When I use create-react-app, I'm able to achieve the production build by following the instructions they have given. However, when I use Bones, I'm unable to achieve the production build. I see that the documentation says we have to use npm start to get the production build, but I have been unsuccessful thus far. How can I do the production build before deploying to Heroku? I have a Procfile that says web: node server/start.js

I've tried deploying to heroku recently and have been unsuccessful. I've tried using different versions of node, npm and webpack to no avail. If someone else can try, please let me know if you are able to deploy or not. To my knowledge the issue seems related to webpack.