Vue via Webpack. A project seed.
Get this repository's latest content inside a new git repository using degit:
npx degit https://github.com/slacktracer/vvw.git --force
Create a .env
file at root level (.
). It will be ignored by git.
Add development environment variables as needed.
# stop and run npm start again after adding new environment variables
BASE_URL=https://api.example.com
Then npm i
...
Then npm start
!
Vue, Vuex and Vue-Router, the very basics for a non-trivial Vue web application.
The Webpack module bundler uses the Babel compiler and the Vue framework loaders (and Babel uses the TypeScript preset) to allow us to use the latest and greatest JS/TS that will run in any browser of our choosing (.browserlistrc)!
Before every commit and npm run patch
the TypeScript compiler type checks the code.
These tools are mostly configured by the following configuration files at root (.
) level:
- .babelrc
And by the following configuration files at source (the ./src
folder) level:
- .babelrc
- tsconfig.json
The project is set up to look for unit tests inside __unit-tests__
folders and run them using Jest.
It is also set up to run end-to-end tests from the cypress/integration
folder (the default) using Cypress.
These tools are mostly configured by the following configuration files at root (.
) level:
- cypress.json
- jest.config.json
On every commit code is type checked, formatted and linted using TypeScript, Prettier and ESLint They all run on staged files only using lint-staged on a pre-commit git hook set up with Husky.
These tools are mostly configured by the following configuration files at root (.
) level:
- .eslintignore
- .eslintrc.json
- .huskyrc.json
- .lintstagedrc.json
- .prettierignore
- .prettierrc
And by the following configuration files at source (the ./src
folder) level:
- .eslintignore
- .eslintrc.json
Finally, the .editorconfig
file is there, at root (.
) level, to make different code editors behave in the same consistent way in regards to details like indentation size etc.
It is supposed to work out of the box with WebStorm and there is a plugin for VS Code.
The following eslint-plugin-vue rules were turned off because they conflict with Prettier.
The rationale is that overall code formatting/style consistency is preferable to following every Vue recommended style (though they are very sensible ๐). A solution to accommodate both does not seem to exist at the time of writing. ๐ ๐คทโโ๏ธ
The @typescript-eslint/no-unused-vars rule is set as an error instead of a warning (the default).
The rationale is that nobody likes stupid unused variables hanging around and making the code look silly and stuff... ๐
These are (allegedly) the most important scripts inside package.json.
Starts everything in development mode.
Runs unit tests using jest.
Runs e2e tests using Cypress in terminal mode (cypress run
).
Updates the patch (SemVer) number, commits, tags and pushes it to the repository.
Runs the TypeScript compiler to type check the code.
Runs Prettier to check the code formatting.
Runs ESLint to... well, lint the code.
These variables should be set at project level:
AWS_ACCESS_KEY_ID
The AWS access key ID. Who would have guessed?
AWS_REGION
The AWS region. But, honestly, it is always the same. You know it.
AWS_SECRET_ACCESS_KEY
Pretty much the same thing as the first one, but this one is seeecret...
BUILDS_BUCKET
:
The name of the bucket for all builds (staging, demo and production).
NODE_ENV
:
It should be production. It's not related to the destination environment but the build mode.
STAGING_BUCKET
The name of the bucket where the latest staging files should be copied to after build.
STAGING_DIST_ID
:
It will be used to create an invalidation on CloudFront after the latest staging files are copied to the staging bucket.
Setting variables for each environment in three easy steps!
- Add the project name to the
package.json
file:
{ "name": "some_project_name", "version": "1.0.0", ... }
-
npm run config
. It will create the.circleci/config.yml
file. -
Create a context for each environment with variables like
BASE_URL
.
Follow this pattern, [project_name]_ENV_[environment]
.
We should end up with something like this:
SOME_PROJECT_NAME_ENV_STAGING
SOME_PROJECT_NAME_ENV_DEMO
SOME_PROJECT_NAME_ENV_PRODUCTION