Webpack was unnecessarily requiring files in webpack_spec_index.js
Serving public/dist/brandable_css/**/*.css in Karma is also
unnecessary
This cuts down error noise in the console when running Karma tests
This also fixes use of globs in the command line, e.g.
yarn run jspec-watch ./spec/javascripts/jsx/gradebook/**Spec.js
Test plan:
- All JS tests pass
flag=none
Change-Id: I82b152bdc70fd77e260ffc27254211b1d0a8bbf5
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/303069
Reviewed-by: Jeffrey Johnson <jeffrey.johnson@instructure.com>
Reviewed-by: Christopher Soto <christopher.soto@instructure.com>
QA-Review: Christopher Soto <christopher.soto@instructure.com>
Product-Review: Aaron Ogata <aogata@instructure.com>
Build-Review: Aaron Ogata <aogata@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
flag = none
Change-Id: I2693b108b02c5d29b6ff05be4e02c7eab83264dc
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/296538
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Tested-by: James Butters <jbutters@instructure.com>
QA-Review: James Butters <jbutters@instructure.com>
Reviewed-by: Andrea Cirulli <andrea.cirulli@instructure.com>
Product-Review: James Butters <jbutters@instructure.com>
Refs FOO-2929
flag=none
The replaces some of the functionality performed in the
ui/index.js entrypoint with the new "engine" which will
eventually hold all the startup helpers for standalone
entrypoints (that don't boot via ui/index.js). For
starters, we've done the loading of the translation file,
the backfill of ENV.LOCALE from the ENV.LOCALES list,
and the (possible) loading of locale polyfills for the
Intl subsystems that are in use.
Test plan:
* Canvas pages come up normally
* Try a locale that requires polyfilling
(recommend Welsh (Cymraeg) in Chrome browser)
* That should still work, you should see console
messages affirming that the locale was polyfilled
for the three Intl subsystems that we use
Change-Id: Ie9b386d5006a03372583240afca06190a4f23ee2
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/294705
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Jacob Burroughs <jburroughs@instructure.com>
QA-Review: Charley Kline <ckline@instructure.com>
Product-Review: Charley Kline <ckline@instructure.com>
Refs FOO-2835
flag=none
After running some performance comparisons, it doesn't look
like omitting the chunk hashes from their filenames (in order
to cache-bust after they change) makes any measureable
difference in run time or memory usage. And there were some
engineers surprised by not getting new chunks into their
browsers after making code changes, because the browser was
still using an old cached copy. So it seems best to just
always put the hashes on the chunk.
N.b.: in a production build, filenames for JS assets *always*
include hashes since the caching/CDN environment there is
much more complex.
This commit also sneaks down the max node.js heap size from a
gargantuan 8GB to "merely" 5GB, in response to smaller
memory requirements after the recent optimization work. It
may be able to go smaller yet, but best to be conservative
about that since overflowing the heap causes webpack to die.
Test plan:
* rm -rf public/dist/webpack*
* Run 'yarn webpack'
* Examine the public/dist/webpack-dev directory; the files
in there should all include hashes in their filenames
(i.e. something like qr_mobile_login-c-1f0c369571.js
instead of just qr_mobile_login-c.js)
Change-Id: I9a572aaf959676656c6f94bd3f9ff81a6cf1f1c9
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/295185
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Sean Scally <sean.scally@instructure.com>
QA-Review: Charley Kline <ckline@instructure.com>
Product-Review: Charley Kline <ckline@instructure.com>
refs FOO-2801
flag = none
[change-merged][build-registry-path=jenkins/canvas-lms/foo-2801]
gems/canvas_i18nliner is now a package @instructure/i18nliner-canvas and
lives in the same repo on github along with the 3 other i18nliner
libraries.. this was done to make it easier for maintainers to deal with
this code, since changing one part may break the other due to how
they're architected
the source on github: https://github.com/instructure/i18nliner-js
~ test plan ~
build is still OK, this only affects the generation of files, and those
i manually verified to be identical before and after
Change-Id: I78afa8a808f1699c10aced8466cfade066848bc9
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/294209
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Charley Kline <ckline@instructure.com>
QA-Review: Charley Kline <ckline@instructure.com>
Product-Review: Charley Kline <ckline@instructure.com>
refs FOO-2835
flag = none
apply the same treatment we did in FOO-2801 for canvas's locale data
files but this time for @formatjs ones... i arrived at the list of those
4 files/folders through the webpack analyzer: you see them very big and
taking up most of the bundle space
this does NOT implement cache busting, like we do for most static
assets, and we probably should in case we ever update the @formatjs
packages
~ test plan ~
polyfills are still installed where applicable
Change-Id: I42892000d05cac408f9366b204ed77939210c908
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/294596
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Charley Kline <ckline@instructure.com>
Product-Review: Charley Kline <ckline@instructure.com>
QA-Review: Charley Kline <ckline@instructure.com>
fixes FOO-2835
flag = none
these adjustments make the development build and incremental build a
little faster and use less memory
- lowering the parallelism parameter helps with the memory usage
- fewer module resolve paths result in fewer i/o calls, ideally we do
away with everything inside resolve.modules and resolve.alias
~ test plan ~
dev build is faster for you, and/or uses less memory, i've been testing
memory usage with libmemoryusage on linux, but there's also a
cross-platform node one called "clinic" that i had success with in the
past
memusage npx webpack
# or
npm i -g clinic
clinic doctor -- npx webpack
Change-Id: I1f5931ac6bd01447628a5d7a173e58f657a41a5e
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/294374
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Aaron Ogata <aogata@instructure.com>
QA-Review: Aaron Ogata <aogata@instructure.com>
Product-Review: Ahmad Amireh <ahmad@instructure.com>
refs FOO-2835
flag = none
there's no need for the custom IgnoreErrors plugin anymore since the
esmac plugin now has an option for bypassing specific violations
~ test plan ~
webpack build still reports on access control violations
Change-Id: I684ce4754f6afbf478daf27c3f6d1b9c4dfc161a
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/294369
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Charley Kline <ckline@instructure.com>
QA-Review: Charley Kline <ckline@instructure.com>
Product-Review: Charley Kline <ckline@instructure.com>
refs FOO-2835
flag = none
there are no behavioral changes, only what was necessary to do the
upgrade, see inline comments for explanation where it was warranted
Change-Id: I737f31a210365f190ddb606e96e8eb84e2359e0d
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/294133
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Aaron Ogata <aogata@instructure.com>
Reviewed-by: Charley Kline <ckline@instructure.com>
QA-Review: Aaron Ogata <aogata@instructure.com>
Product-Review: Aaron Ogata <aogata@instructure.com>
refs FOO-2835
flag = none
hoist tinymce to the top since we're using the same version as the RCE,
this way we don't end up with 2 separate installations
that strange CSS require() call has to be relative for a reason i don't
have neither time nor desire to unravel
there was a discrepancy in the noParse directive between our webpack
config in test and outside of test: the test one was excluding the
entirety of tinymce, which is fine for the main tinymce module but not
so for the "icons" one that the rce package depends on. This was working
OK because the test config was ignoring the top-level tinymce icons
module, which is never required, but now that it's getting required,
it fell apart. I kept to the non-test version where we exclude only the
main module "tinymce.js", as there's no value beyond that.
~ test plan ~
the RCE still works (e.g. in assignment edit page) and looks OK
Change-Id: I664930753189d8f3966ddec0d0340ba100af6ab3
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/294132
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Charley Kline <ckline@instructure.com>
QA-Review: Charley Kline <ckline@instructure.com>
Product-Review: Charley Kline <ckline@instructure.com>
Also marks a handful of dirs to proove the tooling
Change-Id: I2e19b3861dbf626efd9361829454b6eb16224755
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/292044
Reviewed-by: Ahmad Amireh <ahmad@instructure.com>
Product-Review: Ahmad Amireh <ahmad@instructure.com>
Tested-by: Jacob Burroughs <jburroughs@instructure.com>
QA-Review: Jacob Burroughs <jburroughs@instructure.com>
Add a confirmation modal when restoring a revision.
closes: LS-3179
flag= none
Test plan:
- Create a new page in a course
- Set that page as front page
- Make a change in the page body
- Go to the page history
- Look for the previous revision and click the “Restore this
revision” link
- Expect a confirmation modal to appear.
- Click Restore and expect the page to be updated to the previous
revision.
Change-Id: I20f1ed6fa29c3c8404f4ff199c9836ee6c780f32
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/292322
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Ed Schiebel <eschiebel@instructure.com>
Reviewed-by: Ed Schiebel <eschiebel@instructure.com>
Product-Review: Allison Howell <allison.howell@instructure.com>
fixes FOO-2930
flag = none
this hasn't been used for quite some time and there's no good reason for
the code to stay, also I noticed it was used in test at some point but
again, no more
~ test plan ~
CI is ok
Change-Id: If4c5dab06d1b5a579d4475c5f3f33ab4f34c5c91
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/291699
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Charley Kline <ckline@instructure.com>
QA-Review: Charley Kline <ckline@instructure.com>
Product-Review: Charley Kline <ckline@instructure.com>
refs DE-938
flag=none
TEST PLAN:
Confirm all builds still run successfully
Confirm all webpack linter jobs still run
Comfirm bundle sizes are appropriately reported
This task removes the webpack linter stage from premerge builds,
spreads the previous tasks around,
and adds a step to postmerge builds to track and report
webpack bundle sizes
Change-Id: I017876726ac0db6f099367b1ecfd086cfb726cf8
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/289680
Reviewed-by: Aaron Ogata <aogata@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Bobby Buten <bobby.buten@instructure.com>
Product-Review: Bobby Buten <bobby.buten@instructure.com>
refs FOO-2696
flag = none
with the recent changes to how we generate the locale bundles, modules
no longer have to have a dependency on their (scope) locale bundle since
they do not exist
with this change, all support for the virtual "i18n!xxx" modules is
removed, as it's been a convenience carried over from the days of
require.js but is proving to be more costly as the tooling landscape
evolves
. test plan .
..... .....
assuming you checked out the change that rewrites all imports to "i18n!"
to use the "useScope" specifier from @canvas/i18n, webpack should still
run
Change-Id: I6e0db400b46133458592976cc4772365efcde317
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/286653
Tested-by: James Butters <jbutters@instructure.com>
Reviewed-by: Charley Kline <ckline@instructure.com>
QA-Review: Charley Kline <ckline@instructure.com>
Product-Review: Charley Kline <ckline@instructure.com>
refs FOO-2720
refs DE-1022
Currently, translations are compiled on a per-scope level. The primary problem by doing this is that each generated scope file contains the translations for all languages, leading users to needing to download translations for languages they will never use.
Instead, we now generate a single translations file per language. This file is loaded and cached by the browser at the beginning of page load.
[change-merged]
[build-registry-path=jenkins/canvas-lms/de-1022]
Change-Id: I64b0d054b04e3d81bb7263650481d1d3fe9a4868
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/284285
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Ahmad Amireh <ahmad@instructure.com>
QA-Review: Ahmad Amireh <ahmad@instructure.com>
Product-Review: Ahmad Amireh <ahmad@instructure.com>
refs FOO-2720
flag = none
Short version: the "_core_en.js" file is no longer loaded in production
as its contents have been merged (there) with the super "core.js" file,
which is targeted for removal later in this series.
Change-Id: I05eb76a2f1cac12b4ab953bad0ca5a49b6ffd37b
---
The problem as I understand it: there are certain phrases that are
marked as "core" because they are used by shared/logic code like
DateTime formatters and are pre-defined in config/locales.yml. These
phrases were being supplied in two distinct files:
- _core_en.js, which includes only the phrases for the "en" language
- _core.js, which includes the phrases for the rest of the supported
locales
_core_en was split because it was deemed necessary to be loaded always,
regardless of the active locale, and that is - as it appears to me, at
least - because some code attempts to look up those phrases at the
time their modules are evaluated. This patch corrects those modules to
defer their lookups until the point where the translations are used,
and when the translations have become available -- just like the rest of
the codebase does.
But if this is true, this begs the question, how come those modules
weren't presenting bugs by using translations for "en" and not for the
target locale? My thinking is that it is only coincidental that they
weren't: should _any_ module that uses I18n be evaluated _before_ any of
those modules, the Webpack plugin will have already loaded the "core"
file, which includes the translations for those phrases in the target
locale. _core_en may not have been loaded by then, but that doesn't
matter because the resolver is gonna look for what's in _core first when
it's available, and it is.
---
What happens in this patch is a slight change to prepare for the full
removal of both _core and _core_en: _core_en is now loaded only in
builds that don't load actual translations because we need the default
values that that file provides. The alternative would've been to go to
each call-site that looks up the phrases provided in _core_en and have
them supply default values, but it's untenable at this point.
This is the list of call-sites and the phrases they look up:
ui/features/calendar/jquery/index.js: time.formats.tiny_on_the_hour
ui/features/quiz_statistics/util/parse_number.js: number.format.delimiter
ui/features/quiz_statistics/util/parse_number.js: number.format.separator
ui/shared/day-substitution/backbone/views/DaySubstitutionView.coffee: date.day_names
ui/shared/syllabus/jquery/calendar_move.js: date.month_names
ui/shared/datetime/jquery/DatetimeField.js: date.formats.medium
ui/shared/datetime/jquery/DatetimeField.js: date.abbr_month_names
ui/shared/datetime/jquery/DatetimeField.js: date.day_names
ui/shared/datetime/jquery/DatetimeField.js: date.abbr_day_names
ui/shared/datetime/jquery/DatetimeField.js: date.datepicker.column_headings
ui/shared/datetime/react/components/render-datepicker-time.js: datepicker.titles.hour
ui/shared/datetime/react/components/render-datepicker-time.js: datepicker.titles.minute
ui/shared/datetime/react/components/render-datepicker-time.js: datepicker.titles.am_pm
ui/shared/handlebars-helpers/dateSelect.js: date.order
ui/shared/handlebars-helpers/dateSelect.js: date.*
ui/shared/i18n/i18nObj.js: number.format
ui/shared/i18n/numberHelper.js: number.format.delimiter
ui/shared/i18n/numberHelper.js: number.format.separator
dateSelect.js is the gnarly one because it seems to be passing through
everything under date.* to God knows who.
The list above was generated with a command similar to this:
grep -rnP "I18n.(t|lookup)\(['\"](date|datetime|number|support|time)\S" ui
---
~ test plan ~
~~~~ ~~~~
- you can still activate a different locale and use something like the
datepicker to normal effect
[change-merged]
[build-registry-path=jenkins/canvas-lms/foo-2720-01]
Change-Id: Ifd5d2d888edc9b89a9930824f2c55fd9c275b03f
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/284102
QA-Review: Ahmad Amireh <ahmad@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Ahmad Amireh <ahmad@instructure.com>
Product-Review: Ahmad Amireh <ahmad@instructure.com>
refs FOO-2720
flag = none
Short version: the "_core_en.js" file is no longer loaded in production
as its contents have been merged (there) with the super "core.js" file,
which is targeted for removal later in this series.
Change-Id: If97f75066aea32dd74c3899db7aec8fcf4cd93db
---
The problem as I understand it: there are certain phrases that are
marked as "core" because they are used by shared/logic code like
DateTime formatters and are pre-defined in config/locales.yml. These
phrases were being supplied in two distinct files:
- _core_en.js, which includes only the phrases for the "en" language
- _core.js, which includes the phrases for the rest of the supported
locales
_core_en was split because it was deemed necessary to be loaded always,
regardless of the active locale, and that is - as it appears to me, at
least - because some code attempts to look up those phrases at the
time their modules are evaluated. This patch corrects those modules to
defer their lookups until the point where the translations are used,
and when the translations have become available -- just like the rest of
the codebase does.
But if this is true, this begs the question, how come those modules
weren't presenting bugs by using translations for "en" and not for the
target locale? My thinking is that it is only coincidental that they
weren't: should _any_ module that uses I18n be evaluated _before_ any of
those modules, the Webpack plugin will have already loaded the "core"
file, which includes the translations for those phrases in the target
locale. _core_en may not have been loaded by then, but that doesn't
matter because the resolver is gonna look for what's in _core first when
it's available, and it is.
---
What happens in this patch is a slight change to prepare for the full
removal of both _core and _core_en: _core_en is now loaded only in
builds that don't load actual translations because we need the default
values that that file provides. The alternative would've been to go to
each call-site that looks up the phrases provided in _core_en and have
them supply default values, but it's untenable at this point.
This is the list of call-sites and the phrases they look up:
ui/features/calendar/jquery/index.js: time.formats.tiny_on_the_hour
ui/features/quiz_statistics/util/parse_number.js: number.format.delimiter
ui/features/quiz_statistics/util/parse_number.js: number.format.separator
ui/shared/day-substitution/backbone/views/DaySubstitutionView.coffee: date.day_names
ui/shared/syllabus/jquery/calendar_move.js: date.month_names
ui/shared/datetime/jquery/DatetimeField.js: date.formats.medium
ui/shared/datetime/jquery/DatetimeField.js: date.abbr_month_names
ui/shared/datetime/jquery/DatetimeField.js: date.day_names
ui/shared/datetime/jquery/DatetimeField.js: date.abbr_day_names
ui/shared/datetime/jquery/DatetimeField.js: date.datepicker.column_headings
ui/shared/datetime/react/components/render-datepicker-time.js: datepicker.titles.hour
ui/shared/datetime/react/components/render-datepicker-time.js: datepicker.titles.minute
ui/shared/datetime/react/components/render-datepicker-time.js: datepicker.titles.am_pm
ui/shared/handlebars-helpers/dateSelect.js: date.order
ui/shared/handlebars-helpers/dateSelect.js: date.*
ui/shared/i18n/i18nObj.js: number.format
ui/shared/i18n/numberHelper.js: number.format.delimiter
ui/shared/i18n/numberHelper.js: number.format.separator
dateSelect.js is the gnarly one because it seems to be passing through
everything under date.* to God knows who.
The list above was generated with a command similar to this:
grep -rnP "I18n.(t|lookup)\(['\"](date|datetime|number|support|time)\S" ui
---
~ test plan ~
~~~~ ~~~~
- you can still activate a different locale and use something like the
datepicker to normal effect
Change-Id: I12ff180da35dcf916137818ab91296dab469f3c0
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/284582
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Aaron Ogata <aogata@instructure.com>
QA-Review: Aaron Ogata <aogata@instructure.com>
Product-Review: Ahmad Amireh <ahmad@instructure.com>
refs FOO-2697
flag = none
webpack config for karma is also independent now and no longer tied to
the main build config, you can find it under ui-build/webpack-for-karma
there are no notable changes outside of breaking that config into a few
files
~ TEST PLAN ~
+-=---------!
- karma/QUnit suite actually runs and passes
Change-Id: Iff474a3d0068441dc8a7c4de605765d936e8ab6d
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/283377
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Charley Kline <ckline@instructure.com>
Reviewed-by: Sean Scally <sean.scally@instructure.com>
QA-Review: Charley Kline <ckline@instructure.com>
Product-Review: Charley Kline <ckline@instructure.com>
refs FOO-2697
flag = none
stop relying on @instructure/ui-babel-preset and instead use exactly the
transforms that we still need today from Babel
transformations that appear to be no longer necessary:
- plugin-transform-destructuring
- plugin-proposal-decorators
- plugin-proposal-class-properties
- plugin-proposal-export-default-from
- plugin-proposal-object-rest-spread
- plugin-proposal-optional-chaining
- plugin-syntax-dynamic-import
- plugin-proposal-private-methods
- postcss et al (we only import 3-4 css sources and they all come from
node_modules, we don't use themeable on core)
transformations that i don't think are necessary:
- babel-plugin-transform-undefined-to-void: because if there is code
that is re-assigning `undefined`, the solution would be not to humor
it but to stop using it and perhaps file a lawsuit
babel deps were pinned to avoid semver upgrading, because upgrading
within the 7 line is already breaking us and i'll deal with that
another day
~ TEST PLAN ~
\ ---- ---- /
- you can run webpack locally and see no visual artifacts
Change-Id: I64eb9a7ac94e17f730686f579cf67cd8bd4e12f2
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/283142
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Sean Scally <sean.scally@instructure.com>
Reviewed-by: Charley Kline <ckline@instructure.com>
Product-Review: Charley Kline <ckline@instructure.com>
QA-Review: Charley Kline <ckline@instructure.com>
flag=none
test-plan:
- crystalball map still generates with istanbul
Change-Id: Ie1be76ba9f1ecbe55af8a3c3a499b6b34f6f5f01
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/282683
Reviewed-by: Manoel Quirino <manoel.quirino@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Brian Watson <bwatson@instructure.com>
Product-Review: Brian Watson <bwatson@instructure.com>
closes MAT-470
flag=new_equation_editor
test plan:
- Navigate to RCE instance
- Open equation editor
- Click a toolbar button
> Verify that the equation is added to the text area
> Verify that the editor preserves the text from
initial and advanced views(use toggle button)
> Verify that modifying text from advanced view
updates the equation preview
test plan:
- Navigate to RCE instance
- Select an already created equation image
> Verify that the modal initializes with the selected
equation
Change-Id: I05255e9cc40441f5a060198a66ac151f63d14fd1
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/278860
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Weston Dransfield <wdransfield@instructure.com>
QA-Review: Weston Dransfield <wdransfield@instructure.com>
Product-Review: David Lyons <lyons@instructure.com>
we likely went over our size allotment due to the introduction
of Thai locale
flag = none
test plan:
• builds pass
Change-Id: I1220298de40753f87db4928d9912858249bc7a71
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/279213
Reviewed-by: Andrea Cirulli <andrea.cirulli@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: August Thornton <august@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
fixes FOO-2493
flag = none
test plan:
• compile assets and ensure Rails and Webpack are ran with
the following ENV variable: RAILS_LOAD_ALL_LOCALES=1
• change your language via profile/course/account to:
• Thai (ไทย)
• verify _most_ strings are being translated properly
• see Thai within our Style Guide for verifications below
• https://instructure.atlassian.net/wiki/spaces/ENG/pages/134802178/ \
Style+Guide+-+Instructure#StyleGuide-Instructure-Thai
• verify the RCE is localized
• verify assignment edit date picker (JQuery) works as expected
• selecting specific days, hours/minutes, and typing
• verify we're formatting the numbers as expected by punching in a
large number into "Points"
• verify the assignment index date picker(React) is localized
• go to calendar and verify the month/day names look appropriate
for the Thai locale
Change-Id: I9de044775b3ee492b8cc96e6d1234d64462c94b6
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/276201
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Product-Review: Jesse Poulos <jpoulos@instructure.com>
Reviewed-by: Ahmad Amireh <ahmad@instructure.com>
QA-Review: Ahmad Amireh <ahmad@instructure.com>
fixes FOO-2494
flag = none
test plan:
• compile assets and ensure Rails and Webpack are ran with
the following ENV variable: RAILS_LOAD_ALL_LOCALES=1
• change your language via profile/course/account to:
• Español (españa)
• verify _most_ strings are being translated properly
• see Spanish (Spain) in our Style Guide for verifications below
• https://instructure.atlassian.net/wiki/spaces/ENG/pages/134802178/ \
Style+Guide+-+Instructure#StyleGuide-Instructure-Spanish(Spain)
• verify the RCE is localized
• verify assignment edit date picker (JQuery) works as expected
• selecting specific days, hours/minutes, and typing
• verify we're formatting the numbers as expected by punching in a
large number into "Points"
• verify the assignment index date picker(React) is localized
• go to calendar and verify the month/day names look appropriate
for the Español (españa) es-ES locale
• please note that we fall back to es Spanish (Latin America) for
Moment and TinyMCE (canvas-rce)
Change-Id: I441d5c15fcfb55c8695d7b82c643ab74c68318b2
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/276642
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Ahmad Amireh <ahmad@instructure.com>
QA-Review: Ahmad Amireh <ahmad@instructure.com>
Product-Review: Ahmad Amireh <ahmad@instructure.com>
This moves us toward resolution of the following warning:
DeprecationWarning: Tapable.plugin is deprecated.
Use new API on `.hooks` instead
Test plan:
- tests pass
Closes FOO-2563
flag=none
Change-Id: I69429eac6e971268b722ed347d7b4a37473cd622
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/278023
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Ahmad Amireh <ahmad@instructure.com>
QA-Review: Ahmad Amireh <ahmad@instructure.com>
Product-Review: Ahmad Amireh <ahmad@instructure.com>
This moves us toward resolution of the following warning:
DeprecationWarning: Tapable.plugin is deprecated.
Use new API on `.hooks` instead
Pork: prettify ui-build/webpack/index.js
Test plan:
- Tests pass
Closes FOO-2562
flag=none
Change-Id: I342d0679c29721866adf979967434b6946f0ef7e
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/277926
Reviewed-by: Ahmad Amireh <ahmad@instructure.com>
Reviewed-by: Eduardo Escobar <eduardo.escobar@instructure.com>
QA-Review: Aaron Shafovaloff <ashafovaloff@instructure.com>
Product-Review: Syed Hussain <shussain@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
minor QOL mainly for me; put webpack-specific configuration in its own
folder, make it portable, and make room for esbuild
the __webpack_public_path__ initializer no longer sources the value from
the build module, instead it uses a pre-defined global that webpack
injects
~ test plan ~
build is OK
Change-Id: I4ba4a3c0cb9175f96096f2b78022e152c04fc75d
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/276183
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Charley Kline <ckline@instructure.com>
QA-Review: Charley Kline <ckline@instructure.com>
Product-Review: Charley Kline <ckline@instructure.com>
Aaron Shafovaloff