canvas-lms/gulpfile.js

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

132 lines
4.0 KiB
JavaScript
Raw Normal View History

/*
* Copyright (C) 2018 - present Instructure, Inc.
*
* This file is part of Canvas.
*
* Canvas is free software: you can redistribute it and/or modify it under
* the terms of the GNU Affero General Public License as published by the Free
* Software Foundation, version 3 of the License.
*
* Canvas is distributed in the hope that it will be useful, but WITHOUT ANY
* WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
* A PARTICULAR PURPOSE. See the GNU Affero General Public License for more
* details.
*
* You should have received a copy of the GNU Affero General Public License along
* with this program. If not, see <http://www.gnu.org/licenses/>.
*/
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
const gulp = require('gulp')
const gulpPlugins = require('gulp-load-plugins')()
const merge = require('merge-stream')
const rename = require('gulp-rename')
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
const DIST = 'public/dist'
const STUFF_TO_REV = [
'public/fonts/**/*.{eot,otf,svg,ttf,woff,woff2}',
'public/images/**/*',
postMessage forwarder iframe: eliminate excess JS Why: - The current way of including the forwarder code involves using a bundle, All the extra unnecessary Canvas code slows things down, costs more to serve, and can cause errors because some things it expects to work don't in the iframe. - This includes the script as a static asset which will be served from the CDN and only be refetched by the client when the the script content changes, otherwise it will be cached for a year (365.2425 days). It will also be gzip-compressed when delivered to web browsers. Credit to Jacob Burroughs for figuring out this approach. Test plan: Note: this is pretty much the same test plan as the next commit so you can test just test that commit. - after checking out code, run `yarn gulp rev` (this may also be done as part of building assets?). - to make sure you get the new code, clear your browser's cache, load a canvas page, and open dev tools. In Network find the (web/doc) request for /post_message_forwarding?target=... and visit the page to make sure it has the new code (with script src="/...lti_post_message_forwarding-1244...js" tag) - launch an LTI tool and send messages to the forwarder iframe (platform storage target) and make sure you get the appropriate response. You can use can use messages like: {"subject":"lti.put_data","key":"a","value":"b","message_id":"12"} {"subject":"lti.get_data","key":"a","message_id":"12"} - send messages from the tool to the parent window and make sure those work too. - embed an LTI tool in RCE content and while still editing the content, send messages from the tool to both the platform storage target and the parent window, as in the previous 2 steps. refs INTEROP-8279 flag=none Change-Id: I0d4ced28efc3c0c7d8180e72d56bab54557d3cce Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/334733 Reviewed-by: Xander Moffatt <xmoffatt@instructure.com> QA-Review: Xander Moffatt <xmoffatt@instructure.com> Product-Review: Evan Battaglia <ebattaglia@instructure.com> Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
2023-12-07 05:27:24 +08:00
'public/javascripts/translations/*.json',
'public/javascripts/lti_post_message_forwarding.js',
]
gulp.task('rev', () => {
const timezonefilesToIgnore = [
'loaded.js',
'locales.js',
'rfc822.js',
'synopsis.js',
'zones.js',
'ca_ES.js',
'de_DE.js',
'fr_FR.js',
'fr_CA.js',
'he_IL.js',
'pl_PL.js',
postMessage forwarder iframe: eliminate excess JS Why: - The current way of including the forwarder code involves using a bundle, All the extra unnecessary Canvas code slows things down, costs more to serve, and can cause errors because some things it expects to work don't in the iframe. - This includes the script as a static asset which will be served from the CDN and only be refetched by the client when the the script content changes, otherwise it will be cached for a year (365.2425 days). It will also be gzip-compressed when delivered to web browsers. Credit to Jacob Burroughs for figuring out this approach. Test plan: Note: this is pretty much the same test plan as the next commit so you can test just test that commit. - after checking out code, run `yarn gulp rev` (this may also be done as part of building assets?). - to make sure you get the new code, clear your browser's cache, load a canvas page, and open dev tools. In Network find the (web/doc) request for /post_message_forwarding?target=... and visit the page to make sure it has the new code (with script src="/...lti_post_message_forwarding-1244...js" tag) - launch an LTI tool and send messages to the forwarder iframe (platform storage target) and make sure you get the appropriate response. You can use can use messages like: {"subject":"lti.put_data","key":"a","value":"b","message_id":"12"} {"subject":"lti.get_data","key":"a","message_id":"12"} - send messages from the tool to the parent window and make sure those work too. - embed an LTI tool in RCE content and while still editing the content, send messages from the tool to both the platform storage target and the parent window, as in the previous 2 steps. refs INTEROP-8279 flag=none Change-Id: I0d4ced28efc3c0c7d8180e72d56bab54557d3cce Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/334733 Reviewed-by: Xander Moffatt <xmoffatt@instructure.com> QA-Review: Xander Moffatt <xmoffatt@instructure.com> Product-Review: Evan Battaglia <ebattaglia@instructure.com> Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
2023-12-07 05:27:24 +08:00
'**/index.js',
].map(f => `!./node_modules/timezone/${f}`)
const timezoneFileGlobs = ['./node_modules/timezone/**/*.js'].concat(timezonefilesToIgnore)
const timezonesStream = gulp
.src(timezoneFileGlobs, {base: './node_modules'})
.pipe(gulpTimezonePlugin())
const customTimezoneStream = gulp
.src('./ui/ext/custom_timezone_locales/*.js')
.pipe(rename(path => (path.dirname = '/timezone')))
.pipe(gulpTimezonePlugin())
let stream = merge(
timezonesStream,
customTimezoneStream,
gulp.src(STUFF_TO_REV, {
base: 'public', // tell it to use the 'public' folder as the base of all paths
postMessage forwarder iframe: eliminate excess JS Why: - The current way of including the forwarder code involves using a bundle, All the extra unnecessary Canvas code slows things down, costs more to serve, and can cause errors because some things it expects to work don't in the iframe. - This includes the script as a static asset which will be served from the CDN and only be refetched by the client when the the script content changes, otherwise it will be cached for a year (365.2425 days). It will also be gzip-compressed when delivered to web browsers. Credit to Jacob Burroughs for figuring out this approach. Test plan: Note: this is pretty much the same test plan as the next commit so you can test just test that commit. - after checking out code, run `yarn gulp rev` (this may also be done as part of building assets?). - to make sure you get the new code, clear your browser's cache, load a canvas page, and open dev tools. In Network find the (web/doc) request for /post_message_forwarding?target=... and visit the page to make sure it has the new code (with script src="/...lti_post_message_forwarding-1244...js" tag) - launch an LTI tool and send messages to the forwarder iframe (platform storage target) and make sure you get the appropriate response. You can use can use messages like: {"subject":"lti.put_data","key":"a","value":"b","message_id":"12"} {"subject":"lti.get_data","key":"a","message_id":"12"} - send messages from the tool to the parent window and make sure those work too. - embed an LTI tool in RCE content and while still editing the content, send messages from the tool to both the platform storage target and the parent window, as in the previous 2 steps. refs INTEROP-8279 flag=none Change-Id: I0d4ced28efc3c0c7d8180e72d56bab54557d3cce Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/334733 Reviewed-by: Xander Moffatt <xmoffatt@instructure.com> QA-Review: Xander Moffatt <xmoffatt@instructure.com> Product-Review: Evan Battaglia <ebattaglia@instructure.com> Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
2023-12-07 05:27:24 +08:00
follow: true, // follow symlinks, so it picks up on images inside plugins and stuff
}),
gulp.src(['node_modules/tinymce/skins/lightgray/**/*'], {
postMessage forwarder iframe: eliminate excess JS Why: - The current way of including the forwarder code involves using a bundle, All the extra unnecessary Canvas code slows things down, costs more to serve, and can cause errors because some things it expects to work don't in the iframe. - This includes the script as a static asset which will be served from the CDN and only be refetched by the client when the the script content changes, otherwise it will be cached for a year (365.2425 days). It will also be gzip-compressed when delivered to web browsers. Credit to Jacob Burroughs for figuring out this approach. Test plan: Note: this is pretty much the same test plan as the next commit so you can test just test that commit. - after checking out code, run `yarn gulp rev` (this may also be done as part of building assets?). - to make sure you get the new code, clear your browser's cache, load a canvas page, and open dev tools. In Network find the (web/doc) request for /post_message_forwarding?target=... and visit the page to make sure it has the new code (with script src="/...lti_post_message_forwarding-1244...js" tag) - launch an LTI tool and send messages to the forwarder iframe (platform storage target) and make sure you get the appropriate response. You can use can use messages like: {"subject":"lti.put_data","key":"a","value":"b","message_id":"12"} {"subject":"lti.get_data","key":"a","message_id":"12"} - send messages from the tool to the parent window and make sure those work too. - embed an LTI tool in RCE content and while still editing the content, send messages from the tool to both the platform storage target and the parent window, as in the previous 2 steps. refs INTEROP-8279 flag=none Change-Id: I0d4ced28efc3c0c7d8180e72d56bab54557d3cce Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/334733 Reviewed-by: Xander Moffatt <xmoffatt@instructure.com> QA-Review: Xander Moffatt <xmoffatt@instructure.com> Product-Review: Evan Battaglia <ebattaglia@instructure.com> Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
2023-12-07 05:27:24 +08:00
base: '.',
})
).pipe(gulpPlugins.rev())
if (
process.env.JS_BUILD_NO_UGLIFY !== '1' &&
(process.env.NODE_ENV === 'production' || process.env.RAILS_ENV === 'production')
) {
const jsFilter = gulpPlugins.filter('**/*.js', {restore: true})
stream = stream
.pipe(jsFilter)
.pipe(gulpPlugins.sourcemaps.init())
.pipe(gulpPlugins.uglify())
.pipe(gulpPlugins.sourcemaps.write('./maps'))
.pipe(jsFilter.restore)
}
stream = stream.pipe(
gulp.src(
[
'./node_modules/@formatjs/intl-datetimeformat/add-all-tz.js',
'./node_modules/@formatjs/intl-datetimeformat/locale-data/*.js',
'./node_modules/@formatjs/intl-numberformat/locale-data/*.js',
postMessage forwarder iframe: eliminate excess JS Why: - The current way of including the forwarder code involves using a bundle, All the extra unnecessary Canvas code slows things down, costs more to serve, and can cause errors because some things it expects to work don't in the iframe. - This includes the script as a static asset which will be served from the CDN and only be refetched by the client when the the script content changes, otherwise it will be cached for a year (365.2425 days). It will also be gzip-compressed when delivered to web browsers. Credit to Jacob Burroughs for figuring out this approach. Test plan: Note: this is pretty much the same test plan as the next commit so you can test just test that commit. - after checking out code, run `yarn gulp rev` (this may also be done as part of building assets?). - to make sure you get the new code, clear your browser's cache, load a canvas page, and open dev tools. In Network find the (web/doc) request for /post_message_forwarding?target=... and visit the page to make sure it has the new code (with script src="/...lti_post_message_forwarding-1244...js" tag) - launch an LTI tool and send messages to the forwarder iframe (platform storage target) and make sure you get the appropriate response. You can use can use messages like: {"subject":"lti.put_data","key":"a","value":"b","message_id":"12"} {"subject":"lti.get_data","key":"a","message_id":"12"} - send messages from the tool to the parent window and make sure those work too. - embed an LTI tool in RCE content and while still editing the content, send messages from the tool to both the platform storage target and the parent window, as in the previous 2 steps. refs INTEROP-8279 flag=none Change-Id: I0d4ced28efc3c0c7d8180e72d56bab54557d3cce Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/334733 Reviewed-by: Xander Moffatt <xmoffatt@instructure.com> QA-Review: Xander Moffatt <xmoffatt@instructure.com> Product-Review: Evan Battaglia <ebattaglia@instructure.com> Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
2023-12-07 05:27:24 +08:00
'./node_modules/@formatjs/intl-relativetimeformat/locale-data/*.js',
],
{
postMessage forwarder iframe: eliminate excess JS Why: - The current way of including the forwarder code involves using a bundle, All the extra unnecessary Canvas code slows things down, costs more to serve, and can cause errors because some things it expects to work don't in the iframe. - This includes the script as a static asset which will be served from the CDN and only be refetched by the client when the the script content changes, otherwise it will be cached for a year (365.2425 days). It will also be gzip-compressed when delivered to web browsers. Credit to Jacob Burroughs for figuring out this approach. Test plan: Note: this is pretty much the same test plan as the next commit so you can test just test that commit. - after checking out code, run `yarn gulp rev` (this may also be done as part of building assets?). - to make sure you get the new code, clear your browser's cache, load a canvas page, and open dev tools. In Network find the (web/doc) request for /post_message_forwarding?target=... and visit the page to make sure it has the new code (with script src="/...lti_post_message_forwarding-1244...js" tag) - launch an LTI tool and send messages to the forwarder iframe (platform storage target) and make sure you get the appropriate response. You can use can use messages like: {"subject":"lti.put_data","key":"a","value":"b","message_id":"12"} {"subject":"lti.get_data","key":"a","message_id":"12"} - send messages from the tool to the parent window and make sure those work too. - embed an LTI tool in RCE content and while still editing the content, send messages from the tool to both the platform storage target and the parent window, as in the previous 2 steps. refs INTEROP-8279 flag=none Change-Id: I0d4ced28efc3c0c7d8180e72d56bab54557d3cce Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/334733 Reviewed-by: Xander Moffatt <xmoffatt@instructure.com> QA-Review: Xander Moffatt <xmoffatt@instructure.com> Product-Review: Evan Battaglia <ebattaglia@instructure.com> Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
2023-12-07 05:27:24 +08:00
base: './node_modules',
}
)
)
return stream
.pipe(gulp.dest(DIST))
.pipe(gulpPlugins.rev.manifest())
.pipe(gulp.dest(DIST))
.pipe(
gulp
.src(['packages/slickgrid/images/*.gif'], {
postMessage forwarder iframe: eliminate excess JS Why: - The current way of including the forwarder code involves using a bundle, All the extra unnecessary Canvas code slows things down, costs more to serve, and can cause errors because some things it expects to work don't in the iframe. - This includes the script as a static asset which will be served from the CDN and only be refetched by the client when the the script content changes, otherwise it will be cached for a year (365.2425 days). It will also be gzip-compressed when delivered to web browsers. Credit to Jacob Burroughs for figuring out this approach. Test plan: Note: this is pretty much the same test plan as the next commit so you can test just test that commit. - after checking out code, run `yarn gulp rev` (this may also be done as part of building assets?). - to make sure you get the new code, clear your browser's cache, load a canvas page, and open dev tools. In Network find the (web/doc) request for /post_message_forwarding?target=... and visit the page to make sure it has the new code (with script src="/...lti_post_message_forwarding-1244...js" tag) - launch an LTI tool and send messages to the forwarder iframe (platform storage target) and make sure you get the appropriate response. You can use can use messages like: {"subject":"lti.put_data","key":"a","value":"b","message_id":"12"} {"subject":"lti.get_data","key":"a","message_id":"12"} - send messages from the tool to the parent window and make sure those work too. - embed an LTI tool in RCE content and while still editing the content, send messages from the tool to both the platform storage target and the parent window, as in the previous 2 steps. refs INTEROP-8279 flag=none Change-Id: I0d4ced28efc3c0c7d8180e72d56bab54557d3cce Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/334733 Reviewed-by: Xander Moffatt <xmoffatt@instructure.com> QA-Review: Xander Moffatt <xmoffatt@instructure.com> Product-Review: Evan Battaglia <ebattaglia@instructure.com> Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
2023-12-07 05:27:24 +08:00
base: 'packages/slickgrid/images',
})
.pipe(gulp.dest(`${DIST}/images/slickgrid`))
)
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
})
gulp.task('watch', () => gulp.watch(STUFF_TO_REV, ['rev']))
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
function gulpTimezonePlugin() {
const through = require('through2')
const wrapTimezone = (code, timezoneName) =>
`// this was autogenerated by gulpTimezonePlugin from the timezone source in node_modules
(window.__PRELOADED_TIMEZONE_DATA__ || (window.__PRELOADED_TIMEZONE_DATA__ = {}))['${timezoneName}'] ${code
.toString()
.replace('module.exports', '')}
`
return through.obj((file, encoding, callback) => {
if (file.isNull()) return callback(null, file)
if (file.isBuffer()) {
const timezoneName = file.path.replace(/.*\/timezone\//, '').replace(/\.js$/, '')
file.contents = Buffer.from(wrapTimezone(file.contents, timezoneName))
return callback(null, file)
}
})
}