Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrating to Bootstrap 4 #142

Closed
matthew-white opened this issue Sep 6, 2018 · 2 comments
Closed

Migrating to Bootstrap 4 #142

matthew-white opened this issue Sep 6, 2018 · 2 comments

Comments

@matthew-white
Copy link
Member

matthew-white commented Sep 6, 2018

Bootstrap 4 was still under development when we started on Central, but now it's stable, and there's only limited support for Bootstrap 3. I think there would be benefits to switching to Bootstrap 4:

  • Bootstrap 4 clearly seems to be the future of Bootstrap, and since we're still somewhat early in Central, I think it'd be nice to move to 4 while it's relatively easy to do so.
  • The source of Bootstrap 4 is Sass rather than Less. We also use Sass, which means that it may be easier for us to make certain kinds of CSS changes simply by making changes through Bootstrap's Sass.
  • JavaScript methods like modal('dispose') seem to remove jQuery event handlers and data.
  • We may be able to leverage bootstrap-vue (or something similar) to reduce some of the complexity around the interaction between Vue and Bootstrap's jQuery plugins.

There is more information on the changes from Bootstrap 3 to 4 here.

@matthew-white matthew-white changed the title Migrate to Bootstrap 4? Migrating to Bootstrap 4 Sep 6, 2018
matthew-white added a commit that referenced this issue Feb 14, 2019
We will need to redo the changes from #44. I think that can be done as
part of #142.
@matthew-white
Copy link
Member Author

Note that after #199, we need to redo the changes from #44. We might be able to do that as part of this issue.

matthew-white added a commit that referenced this issue May 27, 2019
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.
@matthew-white
Copy link
Member Author

This issue is about Bootstrap 4, but there's now a Bootstrap 5. However, I don't think it'd be easy to migrate to Bootstrap 4 or 5. I've filed the issues #984 and #985 about how to proceed given our use of Bootstrap 3. I'll go ahead and close out this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant