Comments (7)
I'm with Gabriel on this one. I think as an educational tool, it makes the most sense to just call them two separate processes and have the students run them in separate terminals. We could tell them that there are more sophisticated tools out there if they want to explore them, but I think we should be optimizing for understanding over simplicity of execution.
from boilermaker.
I think my strongest objection is our use of &
to run the job as background. Students seem to have a knack for closing their terminals in ways that leave behind zombie processes.
from boilermaker.
I hear that. I actually try not to use that myself, because I don't like mixing the output of two separate processes in one terminal window. I would almost say we can just remove the combined script and instruct them to run separate build and server processes (at a minimum). Students should graduate understanding that sometimes they have to run multiple scripts in parallel…
…of course, if this happened I know we would get help tickets every single cohort with students forgetting to run the build / relying on a stale build. But maybe we shouldn't be optimizing for reduction of help tickets.
from boilermaker.
Popping into this discussion to offer a comment of questionable value: on all my current projects, I've found that just using Parcel is totally the way to go for building a frontend. It doesn't have a quick way to connect to an express server, but it would be straightforward to write a parcel plugin that:
- Looks for
${bundler.options.rootDir}/server.js
- Requires it
- Calls it with
bundler.server
(Parcel plugins are just functions which are called with the bundler.)
Bonus points if it also provides a command that will do this, only without the bundler and with an express server serving on $PORT
and statically serving dist
(which parcel bundles to).
Arguably, suffering through the slings and arrows of outrageous webpack is an important rite of passage, but my current life is better this way for sure.
from boilermaker.
I'm not totally against this, though I'd ideally maybe like to preserve some way of optionally running the build and server as separate processes so I can teach about running them in separate terminal panes.
Also ideally, I would like to ensure that editing client files re-runs the build, but editing server files only restarts the server (and doesn't trigger a cold rebuild) – knowing how sophisticated the Webpack devs are in general, I would hope this is possible, but I haven't looked into it. EDIT: this isn't a must-have though.
These points are admittedly more geared towards having a flexible and efficient dev environment than a simple environment. I might however argue that conflating the build with the server, as in webpack-dev-middleware
, is conceptually muddying for students even if it leads to fewer headaches during development.
It seems to me we need to decide what our priorities are vis-à-vis:
- paving the way for a smooth development / debugging process (cutting down on bugs)
- separating concepts for clearer education (ensuring students understand what a build is)
- separating concerns for easier adaptation of other libs / tech (e.g. React-Native, Firebase, etc.)
- creating a replicable model for students to apply to other tech stacks / boilerplates (e.g. CRA)
from boilermaker.
PS Re: stale bundle issues, there are a couple of approaches to consider:
- Some sort of Hot Module Replacement, perhaps via
webpack-dev-middleware
- Bring back LiveReload, which was temporarily replaced when Webpack 4 was released. EDIT: looks like
webpack-livereload-plugin
now works with Webpack 4.
from boilermaker.
Oh and also there's the concurrently
package, which color-codes the concurrent tasks by namespace (and does a whole bunch more besides). Might be worth considering. I think we used to have this in https://github.com/FullstackAcademy/bones, but eventually it got a bit overwrought and @queerviolet switched to using a dev.js
script. That is adding a lot of complexity to a student platform however.
EDIT: found where the old dev
npm script using concurrently
was switched to running the dev.js
file instead, see here.
-"dev": "cross-env NODE_ENV=development concurrently --kill-others --prefix \"[{name}]\" --names \"BUILD,SERVE\" -c \"bgBlue.bold.black,bgGreen.bold.black\" \"npm run build-dev\" \"npm run start-dev\"",
+"dev": "node dev"
Since then, it looks like the concurrently usage docs have been updated for some fancy features such as wildcards & npm run -> npm:
prefixes, possibly making concurrently
more usable.
from boilermaker.
Related Issues (20)
- npm-merge-driver breaks heroku deployment HOT 2
- Do we need to destroy the session when a user logs out? HOT 1
- Babel stage-X plugins deprecated HOT 1
- make Prettier opt-out
- dev mode webpack HOT 1
- Demonstrate proper security (do not use req.body directly) HOT 1
- BUG: seed file, process.env.NODE_ENV = 'test', reference error 'after is not defined' HOT 3
- Prefer capability sniffing to environment check? HOT 3
- Run the build as part of travis testing?
- Make the travis.yml read the db name from the package.json?
- Run npm audit & also remove any obsolete deps
- Consider switching from Enzyme to React-Testing-Library HOT 2
- Use Volleyball instead of Morgan? HOT 1
- New syntax needed with "history" HOT 1
- Regression bug: Husky broken HOT 1
- js-yaml high security vulnerability
- Unable to deploy Google OAuth on herokuapp.com HOT 1
- Travis CI testing fails because of missing 'secrets.js' require in server/index.js
- As a customer/visitor, I want to be able to access a deployed version of the website so I can browse and purchase products.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from boilermaker.