See how a minor change to your commit message style can make a difference.
git commit -m"<type>(<optional scope>): <description>" \ -m"<optional body>" \ -m"<optional footer>"
See how a minor change to your commit message style can make a difference.
git commit -m"<type>(<optional scope>): <description>" \ -m"<optional body>" \ -m"<optional footer>"
| Angular CLI version | Angular version | Node.js version | TypeScript version | RxJS version | |
|---|---|---|---|---|---|
| ~16.0.0 | ~16.0.0 | ^16.13.0 || ^18.10.0 | >=4.9.5 <5.1.0 | ^6.5.5 || ^7.4.0 | |
| ~15.2.0 | ~15.2.0 | ^14.20.0 || ^16.13.0 || ^18.10.0 | >=4.8.4 <5.0.0 | ^6.5.5 || ^7.4.0 | |
| ~15.1.0 | ~15.1.0 | ^14.20.0 || ^16.13.0 || ^18.10.0 | >=4.8.4 <5.0.0 | ^6.5.5 || ^7.4.0 | |
| ~15.0.5 | ~15.0.4 | ^14.20.0 || ^16.13.0 || ^18.10.0 | ~4.8.4 | ^6.5.5 || ^7.4.0 | |
| ~14.3.0 | ~14.3.0 | ^14.15.0 || ^16.10.0 | >=4.6.4 <4.9.0 | ^6.5.5 || ^7.4.0 | |
| ~14.2.0 | ~14.2.0 | ^14.15.0 || ^16.10.0 | >=4.6.4 <4.9.0 | ^6.5.5 || ^7.4.0 | |
| ~14.1.3 | ~14.1.3 | ^14.15.0 || ^16.10.0 | >=4.6.4 <4.8.0 | ^6.5.5 || ^7.4.0 | |
| ~14.0.7 | ~14.0.7 | ^14.15.0 || ^16.10.0 | >=4.6.4 <4.8.0 | ^6.5.5 || ^7.4.0 | |
| ~13.3.0 | ~13.3.0 | ^12.20.2 || ^14.15.0 || ^16.10.0 | >=4.4.4 <4.7.0 | ^6.5.5 || ^7.4.0 |
While the following structure is not an absolute requirement or enforced by the tools, it is a recommendation based on what the JavaScript and in particular Node community at large have been following by convention.
Beyond a suggested structure, no tooling recommendations, or sub-module structure is outlined here.
lib/ is intended for code that can run as-issrc/ is intended for code that needs to be manipulated before it can be used| { | |
| "name": "workshop-setup", | |
| "version": "1.0.0", | |
| "description": "This is the common setup script for most of my workshops", | |
| "bin": "./setup.js" | |
| } |
| .pnp.* | |
| .yarn/* | |
| !.yarn/patches | |
| !.yarn/plugins | |
| !.yarn/releases | |
| !.yarn/sdks | |
| !.yarn/versions |
React recently introduced an experimental profiler API. This page gives instructions on how to use this API in a production release of your app.
Table of Contents
React DOM automatically supports profiling in development mode for v16.5+, but since profiling adds some small additional overhead it is opt-in for production mode. This gist explains how to opt-in.
2019 update: this essay has been updated on my personal site, together with a followup on how to get started
2020 update: I'm now writing a book with updated versions of all these essays and 35 other chapters!!!!
If there's a golden rule, it's this one, so I put it first. All the other rules are more or less elaborations of this rule #1.
You already know that you will never be done learning. But most people "learn in private", and lurk. They consume content without creating any themselves. Again, that's fine, but we're here to talk about being in the top quintile. What you do here is to have a habit of creating learning exhaust. Write blogs and tutorials and cheatsheets. Speak at meetups and conferences. Ask and answer things on Stackoverflow or Reddit. (Avoid the walled gardens like Slack and Discourse, they're not public). Make Youtube videos
Firstly, Create React App is good. But it's a very rigid CLI, primarily designed for projects that require very little to no configuration. This makes it great for beginners and simple projects but unfortunately, this means that it's pretty non-extensible. Despite the involvement from big names and a ton of great devs, it has left me wanting a much better developer experience with a lot more polish when it comes to hot reloading, babel configuration, webpack configuration, etc. It's definitely simple and good, but not amazing.
Now, compare that experience to Next.js which for starters has a much larger team behind it provided by a world-class company (Vercel) who are all financially dedicated to making it the best DX you could imagine to build any React application. Next.js is the 💣-diggity. It has amazing docs, great support, can grow with your requirements into SSR or static site generation, etc.
| git branch -m old_branch new_branch # Rename branch locally | |
| git push origin :old_branch # Delete the old branch | |
| git push --set-upstream origin new_branch # Push the new branch, set local branch to track the new remote |