@edx/studio-frontend
Advanced tools
React front end for edX Studio
Requirements:
To install and run locally:
$ git clone git@github.com:edx/studio-frontend.git
$ cd studio-frontend
$ make up
You can append -detached to the make up command to run Docker in the background.
To install a new node package in the repo (assumes container is running):
$ make shell
$ npm install <package> --save-dev
$ exit
$ git add package.json
To make changes to the Docker image locally, modify the Dockerfile as needed and run:
$ docker build -t edxops/studio-frontend:latest .
Webpack will serve pages in development mode at http://localhost:18011.
The following pages are served in the development:
| Page | URL |
|---|---|
| Assets | http://localhost:18011/assets.html |
| Accessibility Policy | http://localhost:18011/accessibilityPolicy.html |
| Edit Image Modal | http://localhost:18011/editImageModal.html |
Notes:
The development server will run regardless of whether devstack is running along side it. If devstack is not running, requests to the studio API will fail. You can start up the devstack at any time by following the instructions in the devstack repository, and the development server will then be able to communicate with the studio container. API requests will return the following statuses, given your current setup:
| Studio Running? | Logged in? | API return |
|---|---|---|
| No | n/a | 504 |
| Yes | No | 404 |
| Yes | Yes, non-staff account | 403 |
| Yes | Yes, staff account | 200 |
To load studio-frontend components from the webpack-dev-server inside your studio instance running in Devstack:
cms/envs/private.py if it
does not exist already.STUDIO_FRONTEND_CONTAINER_URL = 'http://localhost:18011' to
cms/envs/private.py.make studio-restart.Pages in Studio that have studio-frontend components should now request assets from your studio-frontend docker container's webpack-dev-server. If you make a change to a file that webpack is watching, the Studio page should hot-reload or auto-reload to reflect the changes.
The Webpack development build of studio-frontend is optimized for speeding up developement, but sometimes it is necessary to make sure that the production build works just like the development build. This is especially important when making changes to the Webpack configs.
Sandboxes use the production webpack build (see section below), but they also take a long time to provision. You can more quickly test the production build in your local docker devstack by following these steps:
cms/envs/private.py file in your devstack edx-platform
folder, then make sure the line STUDIO_FRONTEND_CONTAINER_URL = 'http://localhost:18011' is commented out.make studio-restart.make shell and then
npm run build inside the docker container.make copy-dist.make studio-static.Your devstack Studio should now be using the production studio-frontend files built by your local checkout.
It is a good practice to test out any major changes to studio-frontend in a sandbox since it is much closer to a production environment than devstack. Once you have a branch of studio-frontend up for review:
Create a new branch in edx-platform off master.
Edit the package.json in that branch so that it will install
studio-frontend from your branch in review:
"@edx/studio-frontend": "edx/studio-frontend#your-branch-name",
Commit the change and push your edx-platform branch.
Follow this document on provisioning a sandbox using your edx-platform branch.
The sandbox should automatically pull the studio-frontend branch, run the production webpack build, and then install the dist files into its static assets during provisioning.
This all happens automagically on merges to master, hooray! There are just a few things to keep in mind:
Check github, npm, or the npm badge at the top of this README. package.json no longer contains the correct version (on Github), as it creates an odd loop of "something merged to master, run semantic-release" -> "semantic-release modified package.json, better check that in and make a PR" -> "a PR merged to master, run semantic-release", etc. This is the default behavior for semantic-release.
In order for semantic-release to determine which release type (major/minor/patch) to make, commits must be formatted as specified by these Angular conventions. TravisBuddy will let you know if anything is wrong before you merge your PR. It can be difficult at first, but eventually you get used to it and the added value of automatic releases is well worth it, in our opinions.
Note that when you merge a PR to master (using a merge commit; we've disabled squash-n-merge), there are actually 2 commits that land on the master branch. The first is the one contained in your PR, which has been linted already. The other is the merge commit, which commitlint is smart enough to ignore due to these regexes. The point here is that you should not change the default Merge pull request <number> from <branch> message on your merge commit, or else the master build will fail and we won't get a deploy.
If you are making changes to the Dockerfile or docker-compose.yml you may want to include them in the default docker container.
make from-scratchdocker tag edxops/studio-frontend:latest edxops/studio-frontend:latestdocker push edxops/studio-frontend:latestIf you need assistance with this repository please see our documentation for Getting Help for more information.
We use JIRA for our issue tracker, not GitHub Issues. Please see our documentation for tracking issues for more information on how to track issues that we will be able to respond to and track accurately. Thanks!
Contributions are very welcome, but for legal reasons, you must submit a signed individual contributor's agreement before we can accept your contribution. See our CONTRIBUTING file for more information -- it also contains guidelines for how to maintain high code quality, which will make your contribution more likely to be accepted.
Please do not report security issues in public. Please email security@edx.org.
FAQs
The frontend for the Open edX platform
The npm package @edx/studio-frontend receives a total of 2,907 weekly downloads. As such, @edx/studio-frontend popularity was classified as popular.
We found that @edx/studio-frontend demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 3 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
Security News
Socket’s threat research team has detected six malicious npm packages typosquatting popular libraries to insert SSH backdoors.
Security News
MITRE's 2024 CWE Top 25 highlights critical software vulnerabilities like XSS, SQL Injection, and CSRF, reflecting shifts due to a refined ranking methodology.
Security News
In this segment of the Risky Business podcast, Feross Aboukhadijeh and Patrick Gray discuss the challenges of tracking malware discovered in open source softare.