在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
开源软件名称:cBioPortal/cbioportal-frontend开源软件地址:https://github.com/cBioPortal/cbioportal-frontend开源编程语言:TypeScript 78.1%开源软件介绍:cbioportal-frontendThis repo contains the frontend code for cBioPortal which uses React, MobX and TypeScript. Read more about the architecture of cBioPortal here. Branch Information
Note: you can check the frontend version of the live instance by checking RunMake sure you have installed the node version and yarn version specified in package.json.
Remove old compiled
To install all app and dev dependencies
To build DLLs in common-dist folder (must be done prior to start of dev server)
To start the dev server with hot reload enabled
Example pages:
To run unit/integration tests
To run unit/integration tests in watch mode
To run unit/integration tests in watch mode (where specName is a fragment of the name of the spec file (before
Formatting Code with PrettierJSWhen you make a git commit, PrettierJS will automatically run in write mode on all the files you changed, and make formatting adjustments to those entire files as necessary, before passing them through to the commit (i.e. this is a "pre-commit git hook"). No action from you is necessary for this. You may observe that your changes don't look exactly the same as you wrote them due to formatting adjustments. When you make a pull request, CircleCI will run PrettierJS in check mode on all of the files that have changed between
your pull request and the base branch of your pull request. If all of the files are formatted correctly, then the
CircleCI
This will make PrettierJS run through the same files that CircleCI checks (i.e. all files changed since the base branch)
but in write mode and thus adjust those files to have correct formatting. When you make this update, the CircleCI
Changing the URL of APIIf the version of the desired API URL is the same as the one used to generate
the typescipt client, one can change the
Check in cBioPortal contextGo to https://cbioportal.org ( In your browser console set:
This will use whatever you are running on
or clear entire local storage
You can also use a netlify deployed cbioportal-frontend pull request for serving the JS:
Run e2e-testsEnd-to-end tests can be run against public cbioportal instances or against a local dockerized backend. These two e2e-tests types are referred to as
Run of |
context | BACKEND var | comments |
---|---|---|
Local | mandatory | |
CircleCI | mandatory for feature branches | not for master or rc builds |
CircleCI+PR | optional | 1. When specified, GitHub PR must be of 'draft' state. 2. When not-specified, backend branch will mirror frontend branch (rc frontend vs. rc backend) |
The value of the BACKEND
variable must be formatted as <BACKEND_GITHUB_USER>:<BACKEND_BRANCH>
. For example, when the /env/custom.sh file contains export BACKEND=thehyve:uwe7872A
this is interpreted as a requirement for the commit uwe7872A
of the github.com/thehyve/cbioportal repository.
Using the BACKEND
variable e2e-localdb tests can be conducted against any backend version. This poses a risk when testing in CircleCI+PR context, i.e., tests show up as succesful but should have failed against the backend version that compatible with the target cbioportal-frontend branch. To guard against this and prevent merging of incompatible branches into cbioportal-frontend the e2e-localdb tests enforce the use of draft pull requests (see here for more info). When a cBioPortal backend version is specified (i.e., may require a not yet merged backend branch) and the branch is part of a pull request, the pull request must be in state draft. Only when the BACKEND
variable is not defined a (non-draft) e2e-localdb tests will be conducted on branches that are part of pull requests. Needles to say, pull request should for this and other reasons only be merged when the e2e-localdb tests succeed!
When the BACKEND
variable is not set, the backend version will be set to the target branch of the pull request, i.e. a pull request to 'rc' branch will be tested against the 'rc' branch of the backend.
Some random remarks on e2e-test development
$('id=test')
does not work; this should be $([id=test])
. I was not able to find documentation of v4 selectors.screenshots/diff
and screenshots/error
folders. These are a valuable asset to debug tests on when developing in Local context.browser.debug()
. When placing this command in the test code and using the run_local_screenshot_test.sh
facility, a prompt becomes available on the command line that allows testing of DOM selectors in the webbrowser. In addition, the browser window is available on screen; opening of DevTools allows to explore the DOM and observe the effects of webdriverio commands on the command line.flaky
tests. Typically, flaky test run well on the local system used for development (that has plenty of free resources at moment of test), but fail often on a CI system. Often this is the result of longer times needed page/component update causing tests to fail because the test evaluates a condition before it is loaded. In webdriverio the waitForExist()
, waitForVisible()
and waitFor()
method should be used to pause test execution until the page has been updated. Sometimes it is needed to wait for the appearance of a DOM element which presence is tested.browser.waitForExist('id=button');
assert($('id=button'));
Making e2e-tests follows the current procedure for the e2e-tests:
./end-to-end-test/local/specs
or ./end-to-end-test/remote/specs
directory../end-to-end-test/local/studies
directory.Here are some errors that have been encountered and are hard to debug.
This error occurs when an e2e test tries to take a screenshot of an element that doesn't exist.
This error occurs in CircleCI when the reference screenshot file is somehow corrupted. It can be fixed by deleting and updating the reference screenshot.
We are utilizing yarn workspaces
to maintain multiple packages in a single repo (monorepo). The monorepo approach is an
efficient way of working on libraries in the same project as the application that is their primary consumer.
The cbioportal-frontend
is the main web application workspace. It is used to build and deploy the cBioPortal frontend webapp.
Workspaces under packages
directory are separate modules (npm packages) designed to be imported by cbioportal-frontend
workspace as well as by external projects.
Please note: config
and typings
directories under the packages
directory are NOT workspaces or packages. They are intended to share common settings among all packages under the packages
directory.
To add a new workspace, create a new directory under packages
and add a package.json
file. (See cbioportal-frontend-commons
workspace for example configuration).
The recommended way to add a new dependency to an existing workspace is to run yarn workspace <workspace name> add <package name>
instead of just yarn add <package name>
. For example, run yarn workspace cbioportal-frontend add lodash
instead of yarn add lodash
.
Similarly, to remove a package, run yarn workspace <workspace name> remove <package name>
.
Please abide by the following rules for importing dependencies in a monorepo:
cbioportal-frontend
repository, import modules from packages using the package's alias:// CORRECT, uses alias:
import {something} from 'cbioportal-frontend-commons'
// INCORRECT, uses relative paths:
`import {something} from ../../packages/cbioportal-frontend-commons/src/lib/someLib`
When working on a package, never import custom code from outside that package unless you really intend for that package to be a dependency. For example, commons packages should not import from the main cbioportal project.
Avoid circular dependencies at all costs. For example, while it is okay to import a module from cbioportal-frontend-commons
in react-mutation-mapper
, there should not be any imports from react-mutation-mapper
in cbioportal-frontend-commons
. If you happen to need some component from from react-mutation-mapper
in cbioportal-frontend-commons
, consider moving that component into cbioportal-frontend-commons
package.
Remember that the packages are used by other projects and compatibility needs to be carefully managed.
When you update code under packages a new version of changed packages automatically published once the code is merged to master. However, in a rare case when you would like to set a custom package version, you can run
yarn run updatePackageVersion
Alternatively you can manually set a custom version. When updating manually you should update the version number in the corresponding package.json
as well as the dependencies of other packages depending on the package you update. For example if you update the cbioportal-frontend-commons
version from 0.1.1
to 0.1.2-beta.0
, corresponding cbioportal-frontend-commons
dependency in the package.json
for react-mutation-mapper
and cbioportal-frontend
should also be updated to the new version.
Note that when setting a custom version if you want the next published package version to be, for example, 1.0.6
, then you should set the new version to 1.0.6-beta.1
or a similar prerelease version. If you set the custom version to 1.0.6
, the next published version will be 1.0.7
not 1.0.6
. This is because the auto publish script runs in any case to detect changes in all packages including custom versioned packages.
yarn run updateAPI
Components under packages
should only depend on either external node modules or workspaces under packages
.
Please make sure to not introduce any dependencies from cbioportal-frontend
workspace when updating or adding new files under packages
.
cbioportal-frontend-commons is a separate public npm library which contains basic utility functions and components.
react-mutation-mapper is a separate public npm library that contains the Mutation Mapper and related components.
2023-10-27
2022-08-15
2022-08-17
2022-09-23
2022-08-13
请发表评论