4fe9f01972
This change adds support for typescript transpilation to our frontend
build via babel, and also updates eslint and canvas_i18nliner to be
able to understand typescript as well. The main goal of this PS is to
enable developers to add typescript code to the Canvas codebase but to
be unopinionated about how type-checking is done; at this stage types
will only be checked by running the new `check:ts` or `check:js`
scripts (which run the typescript compiler directly), or via
integration with an IDE like RubyMine or VS Code.
closes LS-2430
flag = none
Test plan:
BUILD STEPS:
- FE build, i18n build, and tests pass Jenkins
- `bin/rails canvas:compile_assets` still works
- `RAILS_ENV=production bin/rails convas:compile_assets` still works
SPOT CHECKING:
- Starting up rails and run `yarn build:js:watch`
- Click around Canvas and make sure the frontend still loads as
normal
Change-Id: I8bb1a0f065e09496a924708dead6fa4518b59496
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/270401
Reviewed-by: Ahmad Amireh <ahmad@instructure.com>
Reviewed-by: Nate Armstrong <narmstrong@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Ahmad Amireh <ahmad@instructure.com>
Product-Review: Jeff Largent <jeff.largent@instructure.com>
|
||
|---|---|---|
| .. | ||
| activesupport-suspend_callbacks | ||
| acts_as_list | ||
| adheres_to_policy | ||
| attachment_fu | ||
| autoextend | ||
| bookmarked_collection | ||
| broadcast_policy | ||
| canvas_breach_mitigation | ||
| canvas_cache | ||
| canvas_cassandra | ||
| canvas_color | ||
| canvas_crummy | ||
| canvas_dynamodb | ||
| canvas_errors | ||
| canvas_ext | ||
| canvas_http | ||
| canvas_i18nliner | ||
| canvas_kaltura | ||
| canvas_mimetype_fu | ||
| canvas_panda_pub | ||
| canvas_partman | ||
| canvas_quiz_statistics | ||
| canvas_sanitize | ||
| canvas_security | ||
| canvas_slug | ||
| canvas_sort | ||
| canvas_stringex | ||
| canvas_text_helper | ||
| canvas_time | ||
| canvas_unzip | ||
| config_file | ||
| csv_diff | ||
| diigo | ||
| dr_diff | ||
| dynamic_settings | ||
| event_stream | ||
| google_drive | ||
| html_text_helper | ||
| i18n_extraction | ||
| i18n_tasks | ||
| incoming_mail_processor | ||
| inst_access | ||
| json_token | ||
| linked_in | ||
| live_events | ||
| lti-advantage | ||
| lti_outbound | ||
| multipart | ||
| paginated_collection | ||
| plugins | ||
| request_context | ||
| rubocop-canvas | ||
| stringify_ids | ||
| tatl_tael | ||
| turnitin_api | ||
| utf8_cleaner | ||
| workflow | ||
| README.md | ||
| test_all_gems.sh | ||
README.md
Gems
This folder is a place to extract modular functionality from canvas. Canvas's Gemfile arrangement is enabled to read gems from this path locally without installing from a remote source. This is valuable for a few reasons:
- it prevents circular dependencies (bundler won't allow it)
- modularized code cannot bind to specific domain concepts on canvas models
- gems can have their specs run independently, without needing to load all of canvas, saving iteration time
- it allows for eventual build optimization via only running specs for the transitive closure of parents depending on a gem where a change is.
- it gives ENGINES extracted from canvas (see the "engines" directory) a place to reference code shared with canvas without it being packaged into the canvas monolith directly.
There are some tradeoffs:
- spreads canvas over more subdirectories, giving some mental overhad to traversing the entire codebase.
- modular tests necessarily don't test integration with canvas concepts, so solid integration tests in the app are still a requirement.
- total SERIALIZED build time goes up because each gem loads it's specs in a new process rather than all running within an already booted canvas process.
[TODO] eventually write more on whether we feel like those tradeoffs are good ones, and what the best practices are to leverage this pattern for max-gain/min-pain.
Testing
To test all the gems:
cd gems
./test_all_gems.sh
To test an individual gem
Run ./test.sh inside the gem's folder. This is basically the same as:
cd gems/google_drive
bundle
rspec