Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
vueify is now deprecated, and Vue CLI seems to be what is recommended for web apps. Vue CLI is also well documented. To make the switch to Vue CLI, I first created a new project using Vue CLI, then made changes to the project, then moved files from the existing repository to the project. I created the project as follows: $ vue create odk-central-frontend Vue CLI v3.7.0 ? Please pick a preset: Manually select features ? Check the features needed for your project: Babel, Router, Vuex, CSS Pre-processors, Linter, Unit ? Use history mode for router? (Requires proper server setup for index fallback in production) No ? Pick a CSS pre-processor (PostCSS, Autoprefixer and CSS Modules are supported by default): Sass/SCSS (with node-sass) ? Pick a linter / formatter config: Airbnb ? Pick additional lint features: ? Pick a unit testing solution: Mocha ? Where do you prefer placing config for Babel, PostCSS, ESLint, etc.? In dedicated config files I then made these changes to the project: - package.json - Specified options for `npm run build` and `npm run lint`. - Changed .browserslistrc. - Removed favicon.ico, including from the HTML. - Added a copyright notice and license information to files. - Removed dangling commas from some config files. Making the switch entailed quite a few other changes: - I updated my version of Node to 8.16, because Vue CLI recommends 8.11.0+. - Updated Vue from 2.5 to 2.6. See #207. - With vueify, our Babel configuration included the stage 2 preset. However, I think that was just the vueify default, and Babel has since deprecated stage presets. Vue CLI seems to include some polyfills by default, including Promise.prototype.finally(), which we use, so I think we can just use the Vue CLI defaults. As a result, I think we have bumped the major version of Babel. - Vue CLI seems to import styles in a slightly different order from vueify. With vueify, we had App.vue contain the global styles, importing the Bootstrap and IcoMoon CSS. However, before importing App's styles, Vue CLI seems to import the styles of the components that App uses, Alert and Navbar. Instead, we want Vue CLI to import the global styles before Alert's and Navbar's styles. For that reason, we now import the global styles in setup.js. The Boostrap and IcoMoon CSS are now stored in .css files, while the global styles specific to Central are stored in app.scss, outside App.vue. - The Sass in app.scss no longer imports the Bootstrap CSS, so our custom class .navbar-icon-bar no longer @extends the Bootstrap class .icon-bar: the styles are simply copied instead. - Vue CLI threw an error for the Glyphicon url() references in the Bootstrap CSS, so I removed all the Glyphicon-related CSS. We had already removed that CSS in #44, but the removal was undone in #199. See also #142. - I had trouble using relative references to the font assets in icomoon.css, so I moved the font assets to public/ and changed the references to absolute. See https://cli.vuejs.org/guide/html-and-static-assets.html#the-public-folder. I would guess that there is a way to continue using relative references, but it did not seem worth spending too much time on. - Note that Vue CLI copies assets to the dist/ directory: this commit closes #77. - Renamed lib/ to src/. This will make blaming more difficult, but Vue CLI does not have an option to specify a directory other than src/. - Vue CLI flagged imports that should have imported a function individually rather than importing the default export, which I corrected. - Vue CLI flagged dependency cycles that involved src/router.js and src/mixins/conditional-route.js. I resolved those by adding a new file, src/util/router.js. - Vue CLI flagged a component that referenced a nonexistent awaitingResponse property (FormSettings). - Vue CLI includes the command `npm run serve`, which starts a development server that provides hot-module-replacement. However, this wasn't playing well with our NGINX config, so I removed `npm run serve`. Instead, I added `npm run dev`, which works similarly to our previous setup: files are built and outputted to dist/, and if a file is changed, files are rebuilt. Hot-module-replacement is not provided. - Moved index.html to public/. - Note that Vue CLI builds the final index.html: this commit closes #140. - While we have been using Karma and avoriaz, Vue CLI uses JSDOM and Vue Test Utils. Replacing Karma with JSDOM seemed nontrivial, so I updated our Karma config to work with Vue CLI, replacing Vue CLI's default `npm run test:unit` with our own `npm run test`. I'm not sure how robust the Karma config really is, though it seems to be working. I think we will eventually want to migrate to JSDOM and Vue Test Utils. However, now doesn't seem like the right time. - Rather than first running test/setup.js, then *.spec.js, Karma now simply runs test/index.js. This is more performant, avoiding an out-of-memory error. - Removed proxyquireify. Closes #145. - Bumped the major version of the eslint and eslint-plugin-vue dependencies. - Created an additional ESLint config for tests. - Resolved new ESLint errors, including by updating the root config. - I completely removed the existing package-lock.json, opting to rerun `npm install`. - Internal behavior of the Vue router that we relied on during testing changed in a patch version, so we now do not destroy the first component into which we inject the router. See the comments in test/index.js for details. - Since we now do not need to update dependencies from vueify, this commit closes #32. - Updated the CircleCI config. - Updated the readme and a comment in nginx.conf.
- Loading branch information
1 parent
720e9a8
commit 17d5de0