mirror of
https://github.com/xodio/xod.git
synced 2026-02-20 02:01:20 +01:00
chore(infra): run prettier on .md files
This commit is contained in:
Evgeny Kochetkov
56
.github/ISSUE_TEMPLATE.md
vendored
56
.github/ISSUE_TEMPLATE.md
vendored
@@ -4,25 +4,20 @@
|
||||
|
||||
### Environment
|
||||
|
||||
- Scope: desktop IDE, browser IDE, CLI
|
||||
- Version: 0.xx.x | dev <!-- Hit “Help” in the IDE main menu to view -->
|
||||
- OS: Windows 10 | macOS High Sierra (10.13) | Ubuntu 18.04
|
||||
- Machine: i3, 4 GB RAM
|
||||
* Scope: desktop IDE, browser IDE, CLI
|
||||
* Version: 0.xx.x | dev <!-- Hit “Help” in the IDE main menu to view -->
|
||||
* OS: Windows 10 | macOS High Sierra (10.13) | Ubuntu 18.04
|
||||
* Machine: i3, 4 GB RAM
|
||||
|
||||
### Steps to reproduce
|
||||
|
||||
Try to narrow down your scenario to a minimal working/failing example. That is,
|
||||
if you have a big program causing a problem, start with deleting parts not
|
||||
relevant to the issue and observing the result: is the problem still there?
|
||||
Repeat until you get the most straightforward sequence of steps to reproduce
|
||||
the problem without any noise surrounding it.
|
||||
Try to narrow down your scenario to a minimal working/failing example. That is, if you have a big program causing a problem, start with deleting parts not relevant to the issue and observing the result: is the problem still there? Repeat until you get the most straightforward sequence of steps to reproduce the problem without any noise surrounding it.
|
||||
|
||||
1. Open this
|
||||
2. Press that
|
||||
3. Click here and there
|
||||
1. Open this
|
||||
2. Press that
|
||||
3. Click here and there
|
||||
|
||||
If the test program is not trivial, attach its `.xodball`. You’ll have to zip
|
||||
the file as GitHub does not accept file attachments with custom extensions.
|
||||
If the test program is not trivial, attach its `.xodball`. You’ll have to zip the file as GitHub does not accept file attachments with custom extensions.
|
||||
|
||||
### Expected behavior
|
||||
|
||||
@@ -32,22 +27,15 @@ What should happen?
|
||||
|
||||
What’s happen now?
|
||||
|
||||
If it will make the issue more illustrative, attach screenshots or GIF’s of
|
||||
what’s going on.
|
||||
If it will make the issue more illustrative, attach screenshots or GIF’s of what’s going on.
|
||||
|
||||
### Console output <!-- if any -->
|
||||
|
||||
Are there any errors in the console? Press `Ctrl+Shift+I` to open the developer
|
||||
tools and find the “Console” tab there. Error are shown in red. Expand an
|
||||
error, then copy and paste the output verbatim. Use fenced code blocks (triple
|
||||
backticks) to preserve formatting.
|
||||
Are there any errors in the console? Press `Ctrl+Shift+I` to open the developer tools and find the “Console” tab there. Error are shown in red. Expand an error, then copy and paste the output verbatim. Use fenced code blocks (triple backticks) to preserve formatting.
|
||||
|
||||
### How to fix <!-- if you know -->
|
||||
|
||||
If you have an idea on how the bug can be fixed, provide a short
|
||||
description.
|
||||
|
||||
|
||||
If you have an idea on how the bug can be fixed, provide a short description.
|
||||
|
||||
## Refactoring Template <!-- Delete the header -->
|
||||
|
||||
@@ -61,28 +49,23 @@ Provide a description of scope the refactoring would touch.
|
||||
|
||||
Which backward compatibility would be dropped.
|
||||
|
||||
|
||||
|
||||
## Feature/Story Template <!-- Delete the header -->
|
||||
|
||||
### Rationale
|
||||
|
||||
What we have now, what we want then? How the implementation would
|
||||
make the product better for end-users?
|
||||
What we have now, what we want then? How the implementation would make the product better for end-users?
|
||||
|
||||
### Prerequisites
|
||||
|
||||
Refer to issues by their #numbers that should be completed before
|
||||
the development of this issue would make sense
|
||||
Refer to issues by their #numbers that should be completed before the development of this issue would make sense
|
||||
|
||||
### Acceptance criteria
|
||||
|
||||
Provide some steps that an end-user would be able to perform when
|
||||
the feature could be considered as implemented. E.g.:
|
||||
Provide some steps that an end-user would be able to perform when the feature could be considered as implemented. E.g.:
|
||||
|
||||
- [ ] I can click a new Boo menu item
|
||||
- [ ] A dialog appears where I can enter Foo value
|
||||
- [ ] Clicking OK changes all nodes’ labels to the Foo value
|
||||
* [ ] I can click a new Boo menu item
|
||||
* [ ] A dialog appears where I can enter Foo value
|
||||
* [ ] Clicking OK changes all nodes’ labels to the Foo value
|
||||
|
||||
### Out of scope
|
||||
|
||||
@@ -90,8 +73,7 @@ Explicitly list functionality that is not intended to be done with this story.
|
||||
|
||||
### How to implement
|
||||
|
||||
If you have an idea on how to implement it, provide a short
|
||||
description.
|
||||
If you have an idea on how to implement it, provide a short description.
|
||||
|
||||
### How to test
|
||||
|
||||
|
||||
7
.github/PULL_REQUEST_TEMPLATE.md
vendored
7
.github/PULL_REQUEST_TEMPLATE.md
vendored
@@ -1,8 +1,5 @@
|
||||
Use a plain English sentence for the title. Listing closed PR titles for
|
||||
a period should form a human-readable changelog.
|
||||
Use a plain English sentence for the title. Listing closed PR titles for a period should form a human-readable changelog.
|
||||
|
||||
Refer to issues related to the PR.
|
||||
|
||||
In related issues place checkmarks near items that should be considred
|
||||
completed once the PR would be approved. If the PR doesn’t really solve
|
||||
a particular item it’d be easy to uncheck it.
|
||||
In related issues place checkmarks near items that should be considred completed once the PR would be approved. If the PR doesn’t really solve a particular item it’d be easy to uncheck it.
|
||||
|
||||
706
CHANGELOG.md
706
CHANGELOG.md
File diff suppressed because it is too large
Load Diff
120
CONTRIBUTING.md
120
CONTRIBUTING.md
@@ -1,19 +1,12 @@
|
||||
There are several ways you can contribute to XOD. This document is dedicated to
|
||||
contributing to code and issues. Other ways are described in the
|
||||
[Contributor’s guide](https://xod.io/docs/contributing/).
|
||||
There are several ways you can contribute to XOD. This document is dedicated to contributing to code and issues. Other ways are described in the [Contributor’s guide](https://xod.io/docs/contributing/).
|
||||
|
||||
## Improving issues
|
||||
|
||||
Review the [issues](https://github.com/xodio/xod/issues) and use the GitHub
|
||||
reactions to show your attitude. Issues with most reactions take a higher
|
||||
development priority.
|
||||
Review the [issues](https://github.com/xodio/xod/issues) and use the GitHub reactions to show your attitude. Issues with most reactions take a higher development priority.
|
||||
|
||||
Read the issues. If you see some flaws, inconsistencies, or ambiguities point to
|
||||
them in the issue’s comments.
|
||||
Read the issues. If you see some flaws, inconsistencies, or ambiguities point to them in the issue’s comments.
|
||||
|
||||
See what’s coming next in the
|
||||
[milestones](https://github.com/xodio/xod/milestones) section. If an issue is
|
||||
already there, you have a final chance to say “no-oooo!”
|
||||
See what’s coming next in the [milestones](https://github.com/xodio/xod/milestones) section. If an issue is already there, you have a final chance to say “no-oooo!”
|
||||
|
||||
## Creating issues
|
||||
|
||||
@@ -21,69 +14,49 @@ Before creating an issue check if a similar issue already exists.
|
||||
|
||||
There are few categories of issues in the XOD GitHub repository:
|
||||
|
||||
* [Bugs](https://github.com/xodio/xod/issues?q=is%3Aissue+is%3Aopen+label%3At%3Abug):
|
||||
things that are definitely broken;
|
||||
* [Features](https://github.com/xodio/xod/issues?q=is%3Aissue+is%3Aopen+label%3At%3Afeat):
|
||||
new functionality for end-users;
|
||||
* [Tweaks](https://github.com/xodio/xod/issues?q=is%3Aissue+is%3Aopen+label%3At%3Atweak):
|
||||
an inconvenient, annoying behavior that more looks like a bug than a missing
|
||||
feature;
|
||||
* [Refactoring](https://github.com/xodio/xod/issues?q=is%3Aissue+is%3Aopen+label%3At%3Arefactor):
|
||||
notes on code improvements without changes in functionality;
|
||||
* [Chore](https://github.com/xodio/xod/issues?q=is%3Aissue+is%3Aopen+label%3At%3Achore):
|
||||
repository building, testing, maintenance, and DX improvements.
|
||||
* [Bugs](https://github.com/xodio/xod/issues?q=is%3Aissue+is%3Aopen+label%3At%3Abug): things that are definitely broken;
|
||||
* [Features](https://github.com/xodio/xod/issues?q=is%3Aissue+is%3Aopen+label%3At%3Afeat): new functionality for end-users;
|
||||
* [Tweaks](https://github.com/xodio/xod/issues?q=is%3Aissue+is%3Aopen+label%3At%3Atweak): an inconvenient, annoying behavior that more looks like a bug than a missing feature;
|
||||
* [Refactoring](https://github.com/xodio/xod/issues?q=is%3Aissue+is%3Aopen+label%3At%3Arefactor): notes on code improvements without changes in functionality;
|
||||
* [Chore](https://github.com/xodio/xod/issues?q=is%3Aissue+is%3Aopen+label%3At%3Achore): repository building, testing, maintenance, and DX improvements.
|
||||
|
||||
Classify issue you want to create in advance. If it’s more like a feature or an
|
||||
opinionated tweak, use XOD [forum](https://forum.xod.io) to discuss it.
|
||||
Features come from the [Roadmap](https://github.com/xodio/xod/wiki/Roadmap) and
|
||||
community brainstorms. GitHub issues are things to be scheduled, tracked, and
|
||||
implemented, they are *not* a place for discussions.
|
||||
Classify issue you want to create in advance. If it’s more like a feature or an opinionated tweak, use XOD [forum](https://forum.xod.io) to discuss it. Features come from the [Roadmap](https://github.com/xodio/xod/wiki/Roadmap) and community brainstorms. GitHub issues are things to be scheduled, tracked, and implemented, they are _not_ a place for discussions.
|
||||
|
||||
New issues title and body should follow a common structure defined in
|
||||
[ISSUE_TEMPLATE](.github/ISSUE_TEMPLATE.md).
|
||||
New issues title and body should follow a common structure defined in [ISSUE_TEMPLATE](.github/ISSUE_TEMPLATE.md).
|
||||
|
||||
To create a new issue fill in required sections from the issue template and
|
||||
delete sections irrelevant for this issue type.
|
||||
To create a new issue fill in required sections from the issue template and delete sections irrelevant for this issue type.
|
||||
|
||||
## Making changes in the code
|
||||
|
||||
Generally, any change in code should be related to a concrete issue. The common
|
||||
pipeline to get your changes into the master branch is:
|
||||
Generally, any change in code should be related to a concrete issue. The common pipeline to get your changes into the master branch is:
|
||||
|
||||
1. Create a new topic branch to work on the issue
|
||||
2. Write the code, do a series of commits
|
||||
3. Rebase on the `master`
|
||||
4. Test and lint the code
|
||||
5. Create a pull request to the `master`
|
||||
6. Wait for the code review, fix the code, rebase, force push
|
||||
7. Merge to the `master` and delete the topic branch
|
||||
1. Create a new topic branch to work on the issue
|
||||
2. Write the code, do a series of commits
|
||||
3. Rebase on the `master`
|
||||
4. Test and lint the code
|
||||
5. Create a pull request to the `master`
|
||||
6. Wait for the code review, fix the code, rebase, force push
|
||||
7. Merge to the `master` and delete the topic branch
|
||||
|
||||
These steps are described below in details.
|
||||
|
||||
### Creating a topic branch
|
||||
|
||||
Any changes are delivered to XOD via pull requests. So any work should be done
|
||||
in a topic branch. Create a new branch like following:
|
||||
Any changes are delivered to XOD via pull requests. So any work should be done in a topic branch. Create a new branch like following:
|
||||
|
||||
$ git checkout -b fix-101-delete-empty-patch
|
||||
|
||||
Use `<type>-<issue_number>-<slug>` notation for the branch name.
|
||||
|
||||
The type should reflect underlying issue category. Use one of: `fix` (bug fix),
|
||||
`feat` (user story implementation), `tweak`, `refactor`, or `doc`.
|
||||
The type should reflect underlying issue category. Use one of: `fix` (bug fix), `feat` (user story implementation), `tweak`, `refactor`, or `doc`.
|
||||
|
||||
Slug should shortly reflect the issue purpose.
|
||||
|
||||
Do use hyphens, lower case letters and digits, do not use slashes or any other
|
||||
symbols.
|
||||
Do use hyphens, lower case letters and digits, do not use slashes or any other symbols.
|
||||
|
||||
### Writing code
|
||||
|
||||
The code should follow some stylistic rules. These rules are based on
|
||||
[Airbnb JavaScript Style Guide](https://github.com/airbnb/javascript) with
|
||||
slight modifications and enforcements. See
|
||||
[ESLint configuration](./.eslintrc.js) for details. To verify your code follows
|
||||
the rules run:
|
||||
The code should follow some stylistic rules. These rules are based on [Airbnb JavaScript Style Guide](https://github.com/airbnb/javascript) with slight modifications and enforcements. See [ESLint configuration](./.eslintrc.js) for details. To verify your code follows the rules run:
|
||||
|
||||
$ yarn run lint
|
||||
|
||||
@@ -91,21 +64,15 @@ In addition to the style ensure that new functionality is covered by unit tests.
|
||||
|
||||
### Performing commits
|
||||
|
||||
Try to keep changes granular. One commit is a single completed portion of an
|
||||
improvement. A commit, in general, should not break any tests or linting rules.
|
||||
Try to keep changes granular. One commit is a single completed portion of an improvement. A commit, in general, should not break any tests or linting rules.
|
||||
|
||||
We use simplified
|
||||
[Angular](https://gist.github.com/stephenparish/9941e89d80e2bc58a153)-alike
|
||||
convention for commit messages. Subject line should have a form
|
||||
`<type><scope>: <subject>`, e.g.
|
||||
We use simplified [Angular](https://gist.github.com/stephenparish/9941e89d80e2bc58a153)-alike convention for commit messages. Subject line should have a form `<type><scope>: <subject>`, e.g.
|
||||
|
||||
fix(xod-fs): allow empty node lists to be loaded correctly
|
||||
|
||||
The `<type>` should be one of `fix` (bug fix), `feat` (new functionality),
|
||||
`tweak`, `refactor`, `doc`, or `chore` (general code maintenance).
|
||||
The `<type>` should be one of `fix` (bug fix), `feat` (new functionality), `tweak`, `refactor`, `doc`, or `chore` (general code maintenance).
|
||||
|
||||
The `<scope>` should be a name of a package affected by the change. If the
|
||||
change affects several packages, separate them with commas (no spaces).
|
||||
The `<scope>` should be a name of a package affected by the change. If the change affects several packages, separate them with commas (no spaces).
|
||||
|
||||
For the `<subject>` text:
|
||||
|
||||
@@ -117,8 +84,7 @@ Try to keep the whole subject line under 72 symbols.
|
||||
|
||||
### Rebasing on master
|
||||
|
||||
To keep history clean we rebase topic branches rather than merge. Once you want
|
||||
to synchronize with the `master` going ahead do:
|
||||
To keep history clean we rebase topic branches rather than merge. Once you want to synchronize with the `master` going ahead do:
|
||||
|
||||
$ git checkout master
|
||||
$ git pull
|
||||
@@ -129,42 +95,28 @@ Follow Git hints to resolve any conflicts.
|
||||
|
||||
### Testing and linting changes
|
||||
|
||||
There is a series of checks that should be passed for the code to have a chance
|
||||
to be merged into `master`. They are unit tests, linting and possibly other
|
||||
things.
|
||||
There is a series of checks that should be passed for the code to have a chance to be merged into `master`. They are unit tests, linting and possibly other things.
|
||||
|
||||
Run `yarn run verify` to make sure your code doesn’t break anything.
|
||||
|
||||
The checks are performed by
|
||||
[Circle CI](https://circleci.com/gh/xodio/xod/tree/master) in any case, but
|
||||
ensuring your PR would not break anything in advance is a good habit.
|
||||
The checks are performed by [Circle CI](https://circleci.com/gh/xodio/xod/tree/master) in any case, but ensuring your PR would not break anything in advance is a good habit.
|
||||
|
||||
### Creating pull request
|
||||
|
||||
Use GitHub interface to create a pull request from the topic branch to the
|
||||
`master` branch.
|
||||
Use GitHub interface to create a pull request from the topic branch to the `master` branch.
|
||||
|
||||
Fill in the proposed [PULL_REQUEST_TEMPLATE](.github/PULL_REQUEST_TEMPLATE.md).
|
||||
|
||||
### Reviewing and fixing
|
||||
|
||||
We strive to review any PR in one day. To be approved a PR should sustain a
|
||||
review by at least one team member. Bigger PR’s are reviewed by at least two
|
||||
members.
|
||||
We strive to review any PR in one day. To be approved a PR should sustain a review by at least one team member. Bigger PR’s are reviewed by at least two members.
|
||||
|
||||
Very likely, there will be code issues that should be fixed before the merge.
|
||||
We’ll try to describe them as friendly as possible. Fix the issues and add the
|
||||
commits to the same PR.
|
||||
Very likely, there will be code issues that should be fixed before the merge. We’ll try to describe them as friendly as possible. Fix the issues and add the commits to the same PR.
|
||||
|
||||
It could also happen that the PR is no longer can be merged into the `master`
|
||||
automatically because the HEAD went ahead. In this case, rebase on master again
|
||||
and push with `--force`. Yes, you’ll rewrite a history, but as an author of the
|
||||
topic branch, you’re the king of your changes.
|
||||
It could also happen that the PR is no longer can be merged into the `master` automatically because the HEAD went ahead. In this case, rebase on master again and push with `--force`. Yes, you’ll rewrite a history, but as an author of the topic branch, you’re the king of your changes.
|
||||
|
||||
### Merging
|
||||
|
||||
Once the PR is good, it would be merged into the master branch.
|
||||
|
||||
It’s better to delete the merged branch to keep the repository clean. Any new
|
||||
contributions related to the same topic may be performed by passing the whole
|
||||
pipeline again.
|
||||
It’s better to delete the merged branch to keep the repository clean. Any new contributions related to the same topic may be performed by passing the whole pipeline again.
|
||||
|
||||
123
README.md
123
README.md
@@ -1,22 +1,14 @@
|
||||
XOD
|
||||
===
|
||||
# XOD
|
||||
|
||||
[](https://circleci.com/gh/xodio/xod/tree/master)
|
||||
[](https://ci.appveyor.com/project/xod/xod)
|
||||
[](https://circleci.com/gh/xodio/xod/tree/master) [](https://ci.appveyor.com/project/xod/xod)
|
||||
|
||||
XOD is a visual programming language for microcontrollers. For documentation
|
||||
and downloads visit https://xod.io.
|
||||
XOD is a visual programming language for microcontrollers. For documentation and downloads visit https://xod.io.
|
||||
|
||||
This repository contains sources for XOD language core, XOD IDE and XOD standard
|
||||
library. XOD documentation is in the [xod-docs](https://github.com/xodio/xod-docs)
|
||||
repository.
|
||||
This repository contains sources for XOD language core, XOD IDE and XOD standard library. XOD documentation is in the [xod-docs](https://github.com/xodio/xod-docs) repository.
|
||||
|
||||
Development copy setup
|
||||
----------------------
|
||||
## Development copy setup
|
||||
|
||||
We use [Yarn](https://yarnpkg.com/lang/en/) to run routine tasks on source
|
||||
files. Make sure it is available on your system. Clone the repository and set
|
||||
working directory to its root. Then run
|
||||
We use [Yarn](https://yarnpkg.com/lang/en/) to run routine tasks on source files. Make sure it is available on your system. Clone the repository and set working directory to its root. Then run
|
||||
|
||||
$ yarn
|
||||
|
||||
@@ -33,48 +25,39 @@ Open <http://localhost:8080> in your browser.
|
||||
$ yarn build:electron
|
||||
$ yarn start:electron
|
||||
|
||||
Directory structure
|
||||
-------------------
|
||||
## Directory structure
|
||||
|
||||
The project is managed as a [Lerna](https://github.com/lerna/lerna) monorepo and
|
||||
split up in few directories:
|
||||
The project is managed as a [Lerna](https://github.com/lerna/lerna) monorepo and split up in few directories:
|
||||
|
||||
- `packages/` — most of source code is here; navigate to a particular package
|
||||
to see it’s own `README` and get an idea what it is for
|
||||
- `tools/` — utility scripts to assist build process and routine maintenance
|
||||
tasks
|
||||
- `workspace/` — XOD standard library, default projects, and end-to-end
|
||||
fixtures
|
||||
* `packages/` — most of source code is here; navigate to a particular package to see it’s own `README` and get an idea what it is for
|
||||
* `tools/` — utility scripts to assist build process and routine maintenance tasks
|
||||
* `workspace/` — XOD standard library, default projects, and end-to-end fixtures
|
||||
|
||||
Repository commands
|
||||
-------------------
|
||||
## Repository commands
|
||||
|
||||
You can run several commands on source files. They are available as yarn
|
||||
subcommands:
|
||||
You can run several commands on source files. They are available as yarn subcommands:
|
||||
|
||||
- `yarn build` — build, transpile, pack all
|
||||
- `yarn build:electron` — build desktop IDE only
|
||||
- `yarn build:cli` — build CLI tools only
|
||||
- `yarn dev:browser` — run dev-version of browser IDE on localhost
|
||||
- `yarn dist:electron` — build OS-specific distributive of desktop IDE
|
||||
- `yarn test` — run unit tests
|
||||
- `yarn test-cpp` — run C++ code tests
|
||||
- `yarn test-func` — run functional tests
|
||||
- `yarn lint` — run the linter to check code style
|
||||
- `yarn verify` — build, lint, test; run this prior to a pull request
|
||||
- `yarn ci` — install & verify; CI-server uses this command
|
||||
- `yarn start:electron` — starts desktop IDE
|
||||
- `yarn start:spectron-repl` — starts functional tests environment
|
||||
- `yarn storybook` — starts React components viewer for visual inspection
|
||||
- `yarn clean` — remove build artifacts and installed `node_modules`
|
||||
* `yarn build` — build, transpile, pack all
|
||||
* `yarn build:electron` — build desktop IDE only
|
||||
* `yarn build:cli` — build CLI tools only
|
||||
* `yarn dev:browser` — run dev-version of browser IDE on localhost
|
||||
* `yarn dist:electron` — build OS-specific distributive of desktop IDE
|
||||
* `yarn test` — run unit tests
|
||||
* `yarn test-cpp` — run C++ code tests
|
||||
* `yarn test-func` — run functional tests
|
||||
* `yarn lint` — run the linter to check code style
|
||||
* `yarn verify` — build, lint, test; run this prior to a pull request
|
||||
* `yarn ci` — install & verify; CI-server uses this command
|
||||
* `yarn start:electron` — starts desktop IDE
|
||||
* `yarn start:spectron-repl` — starts functional tests environment
|
||||
* `yarn storybook` — starts React components viewer for visual inspection
|
||||
* `yarn clean` — remove build artifacts and installed `node_modules`
|
||||
|
||||
Note that dependencies between tasks are not resolved. `test` and `start:*`
|
||||
expect that the project is already built.
|
||||
Note that dependencies between tasks are not resolved. `test` and `start:*` expect that the project is already built.
|
||||
|
||||
### Scoping
|
||||
|
||||
Many commands (notably `build`, `dev`, `test`) support package scoping to
|
||||
save development time. To rebuild only `xod-project`:
|
||||
Many commands (notably `build`, `dev`, `test`) support package scoping to save development time. To rebuild only `xod-project`:
|
||||
|
||||
$ yarn build --scope xod-project
|
||||
|
||||
@@ -88,52 +71,28 @@ Those are standard [Lerna flags](https://github.com/lerna/lerna#flags).
|
||||
|
||||
`yarn test-func` runs automated end-to-end functional tests.
|
||||
|
||||
You can set `XOD_DEBUG_TESTS` environment variable to keep IDE open on failure:
|
||||
`XOD_DEBUG_TESTS=1 yarn test-func`
|
||||
You can set `XOD_DEBUG_TESTS` environment variable to keep IDE open on failure: `XOD_DEBUG_TESTS=1 yarn test-func`
|
||||
|
||||
Use `yarn start:spectron-repl` to run an interactive session and control the
|
||||
IDE window programmatically.
|
||||
Use `yarn start:spectron-repl` to run an interactive session and control the IDE window programmatically.
|
||||
|
||||
### Running C++ tests
|
||||
|
||||
You need `avr-gcc` and [PlatformIO Core](http://platformio.org/get-started/cli)
|
||||
to be installed system-wide to run C++ code tests. They are available as OS
|
||||
packages for most platforms.
|
||||
You need `avr-gcc` and [PlatformIO Core](http://platformio.org/get-started/cli) to be installed system-wide to run C++ code tests. They are available as OS packages for most platforms.
|
||||
|
||||
License
|
||||
-------
|
||||
## License
|
||||
|
||||
Copyright 2017 XOD LLC.
|
||||
|
||||
This program is free software: you can redistribute it and/or modify it under
|
||||
the terms of the GNU Affero General Public License, version 3, as published by
|
||||
the Free Software Foundation.
|
||||
This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License, version 3, as published by the Free Software Foundation.
|
||||
|
||||
This program 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.
|
||||
This program 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/>.
|
||||
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/>.
|
||||
|
||||
As a special exception, the copyright holders give permission to link the code
|
||||
of portions of this program with the OpenSSL library under certain conditions
|
||||
as described in each individual source file and distribute linked combinations
|
||||
including the program with the OpenSSL library. You must comply with the GNU
|
||||
Affero General Public License in all respects for all of the code used other
|
||||
than as permitted herein. If you modify file(s) with this exception, you may
|
||||
extend this exception to your version of the file(s), but you are not obligated
|
||||
to do so. If you do not wish to do so, delete this exception statement from
|
||||
your version. If you delete this exception statement from all source files in
|
||||
the program, then also delete it in the license file.
|
||||
As a special exception, the copyright holders give permission to link the code of portions of this program with the OpenSSL library under certain conditions as described in each individual source file and distribute linked combinations including the program with the OpenSSL library. You must comply with the GNU Affero General Public License in all respects for all of the code used other than as permitted herein. If you modify file(s) with this exception, you may extend this exception to your version of the file(s), but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. If you delete this exception statement from all source files in the program, then also delete it in the license file.
|
||||
|
||||
Contributing
|
||||
------------
|
||||
## Contributing
|
||||
|
||||
Feel free to contribute to the project! See the general [Contibutor’s
|
||||
guide](https://xod.io/docs/contributing/) and [GitHub contribution
|
||||
guidelines](./CONTRIBUTING.md).
|
||||
Feel free to contribute to the project! See the general [Contibutor’s guide](https://xod.io/docs/contributing/) and [GitHub contribution guidelines](./CONTRIBUTING.md).
|
||||
|
||||
Jetbrains users can benefit from [XOD Jetbrains Live
|
||||
Template](tools/xod-jetbrains-live-template/xod-jetbrains-live-template.md).
|
||||
Jetbrains users can benefit from [XOD Jetbrains Live Template](tools/xod-jetbrains-live-template/xod-jetbrains-live-template.md).
|
||||
|
||||
@@ -6,223 +6,230 @@ A javascript wrapper over the [arduino-cli](https://github.com/arduino/arduino-c
|
||||
|
||||
## How to use
|
||||
|
||||
1. Install it with `npm install -S arduino-cli` or `yarn add arduino-cli`;
|
||||
2. Require in the code `import arduinoCli from 'arduino-cli';`
|
||||
3. Create an instance and pass the path to the installed `arduino-cli` and config:
|
||||
```js
|
||||
const cli = arduinoCli('/bin/arduino-cli', {
|
||||
arduino_data: '~/arduino-cli/data',
|
||||
sketchbook_path: '~/arduino-cli/sketches',
|
||||
});
|
||||
```
|
||||
It will create a config file for the `arduino-cli` in your OS temp directory and pass it to any command you'll call later.
|
||||
4. Then you can run commands, like this:
|
||||
```js
|
||||
cli.version().then(console.log); // "0.2.1-alpha.preview"
|
||||
```
|
||||
1. Install it with `npm install -S arduino-cli` or `yarn add arduino-cli`;
|
||||
2. Require in the code `import arduinoCli from 'arduino-cli';`
|
||||
3. Create an instance and pass the path to the installed `arduino-cli` and config:
|
||||
```js
|
||||
const cli = arduinoCli('/bin/arduino-cli', {
|
||||
arduino_data: '~/arduino-cli/data',
|
||||
sketchbook_path: '~/arduino-cli/sketches',
|
||||
});
|
||||
```
|
||||
It will create a config file for the `arduino-cli` in your OS temp directory and pass it to any command you'll call later.
|
||||
4. Then you can run commands, like this:
|
||||
```js
|
||||
cli.version().then(console.log); // "0.2.1-alpha.preview"
|
||||
```
|
||||
|
||||
## API
|
||||
|
||||
All commands runs asynchronously, so methods return `Promise`s.
|
||||
|
||||
### version()
|
||||
Returns the version of `arduino-cli`.
|
||||
Wraps `arduino-cli version`.
|
||||
|
||||
- Returns `Promise<String>`
|
||||
Returns the version of `arduino-cli`. Wraps `arduino-cli version`.
|
||||
|
||||
* Returns `Promise<String>`
|
||||
|
||||
### dumpConfig()
|
||||
Returns the current config of `arduino-cli` as a plain JS object.
|
||||
Wraps `arduino-cli config dump`.
|
||||
|
||||
- Returns `Promise<Object>`
|
||||
Returns the current config of `arduino-cli` as a plain JS object. Wraps `arduino-cli config dump`.
|
||||
|
||||
* Returns `Promise<Object>`
|
||||
|
||||
### updateConfig(newConfig)
|
||||
|
||||
Replaces old config with the new one.
|
||||
|
||||
Accepts:
|
||||
- `newConfig` `<Object>` — Plain JS object representation of `.cli-config.yml`
|
||||
|
||||
- Returns `<Object>` with the new config
|
||||
* `newConfig` `<Object>` — Plain JS object representation of `.cli-config.yml`
|
||||
|
||||
* Returns `<Object>` with the new config
|
||||
|
||||
### listConnectedBoards()
|
||||
|
||||
A wrapper with a custom extension over `arduino-cli board list`.
|
||||
|
||||
*Custom extension may be removed in the future. See [issue #45](https://github.com/arduino/arduino-cli/issues/45)*
|
||||
_Custom extension may be removed in the future. See [issue #45](https://github.com/arduino/arduino-cli/issues/45)_
|
||||
|
||||
Returns a plain JS object which describes boards connected through serial ports.
|
||||
Also, it extends boards' FQBN with `cpu` option from `boards.txt` if
|
||||
a board is identified (a package installed) and has some options.
|
||||
For example, `Arduino Nano` will be transformed into three items with a modified FQBN and name.
|
||||
Returns a plain JS object which describes boards connected through serial ports. Also, it extends boards' FQBN with `cpu` option from `boards.txt` if a board is identified (a package installed) and has some options. For example, `Arduino Nano` will be transformed into three items with a modified FQBN and name.
|
||||
|
||||
- Returns `Promise<Array<ConnectedBoard>>`
|
||||
* Returns `Promise<Array<ConnectedBoard>>`
|
||||
|
||||
### listInstalledBoards()
|
||||
|
||||
A wrapper with a custom extension over `arduino-cli board listall`.
|
||||
|
||||
*Custom extension may be removed in the future. See [issue #45](https://github.com/arduino/arduino-cli/issues/45)*
|
||||
_Custom extension may be removed in the future. See [issue #45](https://github.com/arduino/arduino-cli/issues/45)_
|
||||
|
||||
Returns a plain JS object with boards, whose packages are installed.
|
||||
Also, it extends boards' FQBN with `cpu` option from `boards.txt` if
|
||||
a board is identified (a package installed) and it has some options.
|
||||
For example, `Arduino Nano` will be transformed into three items with a modified FQBN and name.
|
||||
Returns a plain JS object with boards, whose packages are installed. Also, it extends boards' FQBN with `cpu` option from `boards.txt` if a board is identified (a package installed) and it has some options. For example, `Arduino Nano` will be transformed into three items with a modified FQBN and name.
|
||||
|
||||
- Returns `Promise<Array<InstalledBoard>>`
|
||||
* Returns `Promise<Array<InstalledBoard>>`
|
||||
|
||||
### listAvailableBoards()
|
||||
|
||||
Returns a list of all boards that found in all `package_*_index.json` files.
|
||||
|
||||
- Returns `Promise<Array<AvailableBoard>>`
|
||||
* Returns `Promise<Array<AvailableBoard>>`
|
||||
|
||||
### setPackageIndexUrls(urls)
|
||||
Sets a list of additional package index urls into the config file.
|
||||
Later you can download and install packages with `arduino-cli` (call `core.updateIndex()`).
|
||||
|
||||
Sets a list of additional package index urls into the config file. Later you can download and install packages with `arduino-cli` (call `core.updateIndex()`).
|
||||
|
||||
Accepts:
|
||||
- `urls` `<Array<String>>` — List of URLs of the third-party `package_*_index.json` files
|
||||
|
||||
- Returns `Promise<Array<String>>` with just added URLs
|
||||
* `urls` `<Array<String>>` — List of URLs of the third-party `package_*_index.json` files
|
||||
|
||||
* Returns `Promise<Array<String>>` with just added URLs
|
||||
|
||||
### core.download(progressCallback, packageName)
|
||||
Wraps `arduino-cli core download packageName`.
|
||||
Downloads core and tool archives for the specified package.
|
||||
|
||||
Wraps `arduino-cli core download packageName`. Downloads core and tool archives for the specified package.
|
||||
|
||||
Accepts:
|
||||
- `progressCallback` `<Function>` — A function that will be called on progress with one argument `<ProgressData>`. See details below.
|
||||
- `packageName` `<String>` — A package and architecture to download. May contain a version. For example, `arduino:avr` or `arduino:avr@1.6.9`
|
||||
|
||||
- Returns `Promise<String>` — log
|
||||
* `progressCallback` `<Function>` — A function that will be called on progress with one argument `<ProgressData>`. See details below.
|
||||
* `packageName` `<String>` — A package and architecture to download. May contain a version. For example, `arduino:avr` or `arduino:avr@1.6.9`
|
||||
|
||||
* Returns `Promise<String>` — log
|
||||
|
||||
### core.install(progressCallback, packageName)
|
||||
Wraps `arduino-cli core install packageName`.
|
||||
Downloads and installs core and tool archives for the specified package.
|
||||
|
||||
Wraps `arduino-cli core install packageName`. Downloads and installs core and tool archives for the specified package.
|
||||
|
||||
Accepts:
|
||||
- `progressCallback` `<Function>` — A function that will be called on progress with one argument `<ProgressData>`. See details below.
|
||||
- `packageName` `<String>` — A package and architecture to install. May contain a version. For example, `arduino:avr` or `arduino:avr@1.6.9`
|
||||
|
||||
- Returns `Promise<String>` — log
|
||||
* `progressCallback` `<Function>` — A function that will be called on progress with one argument `<ProgressData>`. See details below.
|
||||
* `packageName` `<String>` — A package and architecture to install. May contain a version. For example, `arduino:avr` or `arduino:avr@1.6.9`
|
||||
|
||||
* Returns `Promise<String>` — log
|
||||
|
||||
### core.list()
|
||||
Wraps `arduino-cli core list`.
|
||||
Returns a list of installed packages.
|
||||
|
||||
- Returns `Promise<Array<InstalledPackages>>`
|
||||
Wraps `arduino-cli core list`. Returns a list of installed packages.
|
||||
|
||||
* Returns `Promise<Array<InstalledPackages>>`
|
||||
|
||||
### core.search(query)
|
||||
Wraps `arduino-cli core search query`.
|
||||
Returns a list of packages found.
|
||||
|
||||
Wraps `arduino-cli core search query`. Returns a list of packages found.
|
||||
|
||||
Accepts:
|
||||
- `query` `<String>` — A search query
|
||||
|
||||
- Returns `Promise<Array<FoundPackages>>`
|
||||
* `query` `<String>` — A search query
|
||||
|
||||
* Returns `Promise<Array<FoundPackages>>`
|
||||
|
||||
### core.uninstall(packageName)
|
||||
Wraps `arduino-cli core uninstall packageName`.
|
||||
Uninstalls the core and tools for the specified package.
|
||||
|
||||
Wraps `arduino-cli core uninstall packageName`. Uninstalls the core and tools for the specified package.
|
||||
|
||||
Accepts:
|
||||
- `packageName` `<String>` — A package identifier, like `arduino:samd`
|
||||
|
||||
- Returns `Promise<String>` — a log
|
||||
* `packageName` `<String>` — A package identifier, like `arduino:samd`
|
||||
|
||||
* Returns `Promise<String>` — a log
|
||||
|
||||
### core.updateIndex()
|
||||
Wraps `arduino-cli core update-index`.
|
||||
Downloads the original `package_index.json` and additional package index files.
|
||||
|
||||
- Returns `Promise<String>` — a log
|
||||
Wraps `arduino-cli core update-index`. Downloads the original `package_index.json` and additional package index files.
|
||||
|
||||
* Returns `Promise<String>` — a log
|
||||
|
||||
### createSketch(sketchName)
|
||||
Wraps `arduino-cli sketch new sketchName`.
|
||||
Creates an empty `sketchName/sketchName.ino` inside the sketchbook directory.
|
||||
|
||||
- Returns `Promise<String>` — a full path to the created `.ino` file
|
||||
Wraps `arduino-cli sketch new sketchName`. Creates an empty `sketchName/sketchName.ino` inside the sketchbook directory.
|
||||
|
||||
* Returns `Promise<String>` — a full path to the created `.ino` file
|
||||
|
||||
### compile(onProgress, fqbn, sketchName[, verbose])
|
||||
Wraps `arduino-cli compile`.
|
||||
Compiles the sketch for the specified board.
|
||||
|
||||
Wraps `arduino-cli compile`. Compiles the sketch for the specified board.
|
||||
|
||||
Accepts:
|
||||
- `onProgress` `<Function>` — A function that is called on new data in `stdout`
|
||||
- `fqbn` `<String>` — A fully-qualified board name. Like `arduino:avr:mega:cpu=atmega2560`
|
||||
- `sketchName` `<String>` — A name of the sketch in the sketchbook directory.
|
||||
It can contain sketch name or full path to the sketch.
|
||||
- `verbose` `<Boolean>` — Verbose output. By default is `false`
|
||||
|
||||
- Returns `Promise<String>` with a log of the compilation process
|
||||
* `onProgress` `<Function>` — A function that is called on new data in `stdout`
|
||||
* `fqbn` `<String>` — A fully-qualified board name. Like `arduino:avr:mega:cpu=atmega2560`
|
||||
* `sketchName` `<String>` — A name of the sketch in the sketchbook directory. It can contain sketch name or full path to the sketch.
|
||||
* `verbose` `<Boolean>` — Verbose output. By default is `false`
|
||||
|
||||
* Returns `Promise<String>` with a log of the compilation process
|
||||
|
||||
### upload(onProgress, port, fqbn, sketchName[, verbose])
|
||||
Wraps `arduino-cli upload`.
|
||||
Uploads the compiled sketch onto the board.
|
||||
|
||||
Wraps `arduino-cli upload`. Uploads the compiled sketch onto the board.
|
||||
|
||||
Accepts:
|
||||
- `onProgress` `<Function>` — A function that is called on new data in `stdout` with a single argument
|
||||
- `port` `<String>` — A port name (e.g., `COM3` or `/dev/tty.usbmodem1411`)
|
||||
- `fqbn` `<String>` — A fully-qualified board name. Like `arduino:avr:mega:cpu=atmega2560`
|
||||
- `sketchName` `<String>` — A name of the sketch in the sketchbook directory.
|
||||
It can contain sketch name or full path to the sketch.
|
||||
- `verbose` `<Boolean>` — Verbose output. By default is `false`
|
||||
|
||||
- Returns `Promise<String>` with a log of the upload process
|
||||
* `onProgress` `<Function>` — A function that is called on new data in `stdout` with a single argument
|
||||
* `port` `<String>` — A port name (e.g., `COM3` or `/dev/tty.usbmodem1411`)
|
||||
* `fqbn` `<String>` — A fully-qualified board name. Like `arduino:avr:mega:cpu=atmega2560`
|
||||
* `sketchName` `<String>` — A name of the sketch in the sketchbook directory. It can contain sketch name or full path to the sketch.
|
||||
* `verbose` `<Boolean>` — Verbose output. By default is `false`
|
||||
|
||||
* Returns `Promise<String>` with a log of the upload process
|
||||
|
||||
### getRunningProcesses()
|
||||
|
||||
Returns a list of running `arduino-cli` processes.
|
||||
|
||||
- Returns `Array<ChildProcess>`
|
||||
* Returns `Array<ChildProcess>`
|
||||
|
||||
### killProcesses()
|
||||
|
||||
Kills all running `arduino-cli` processes.
|
||||
|
||||
- Returns `Boolean` `true`
|
||||
* Returns `Boolean` `true`
|
||||
|
||||
## Types
|
||||
|
||||
### ConnectedBoard
|
||||
- `name` `<String>` — A board name with an added cpu option, if it exists
|
||||
For example, "Arduino/Genuino Uno" or "Arduino/Genuino Mega2560 (ATmega2560 (Mega 2560))"
|
||||
- `fqbn` `<String>` — A fully-qualified board name
|
||||
For example, `arduino:avr:uno` or `arduino:avr:mega2560:cpu=atmega2560`
|
||||
- `port` `<String>` — A port name. Like `/dev/tty.usbmodem1411`
|
||||
- `usbID` `String` — An ID of the board (VID, PID). For example, `2341:0042`
|
||||
|
||||
* `name` `<String>` — A board name with an added cpu option, if it exists For example, "Arduino/Genuino Uno" or "Arduino/Genuino Mega2560 (ATmega2560 (Mega 2560))"
|
||||
* `fqbn` `<String>` — A fully-qualified board name For example, `arduino:avr:uno` or `arduino:avr:mega2560:cpu=atmega2560`
|
||||
* `port` `<String>` — A port name. Like `/dev/tty.usbmodem1411`
|
||||
* `usbID` `String` — An ID of the board (VID, PID). For example, `2341:0042`
|
||||
|
||||
### InstalledBoard
|
||||
- `name` `<String>` — A board name
|
||||
E.G. "Arduino/Genuino Uno" or "Arduino/Genuino Mega2560"
|
||||
- `fqbn` `<String>` — A fully-qualified board name
|
||||
E.G. "arduino:avr:uno" or "arduino:avr:mega2560"
|
||||
- `options` `<Array<Option>>` — a list of options for this board
|
||||
|
||||
* `name` `<String>` — A board name E.G. "Arduino/Genuino Uno" or "Arduino/Genuino Mega2560"
|
||||
* `fqbn` `<String>` — A fully-qualified board name E.G. "arduino:avr:uno" or "arduino:avr:mega2560"
|
||||
* `options` `<Array<Option>>` — a list of options for this board
|
||||
|
||||
### Option
|
||||
|
||||
Object, that represents one group of the board option. For example, CPU Frequency.
|
||||
- `optionName` `<String>` — A human-readable name of the option group ("CPU Frequency")
|
||||
- `optionId` `<String>` — An id of the option from `boards.txt`. E.G. `CpuFrequency`
|
||||
- `values` `<Array<OptionValue>>` — a list of option values, that represented as objects
|
||||
with two fields
|
||||
- `name` `<String>` — A human-readable option name ("80 MHz")
|
||||
- `value` `<String>` — A value, that will be used by tools. ("80")
|
||||
|
||||
* `optionName` `<String>` — A human-readable name of the option group ("CPU Frequency")
|
||||
* `optionId` `<String>` — An id of the option from `boards.txt`. E.G. `CpuFrequency`
|
||||
* `values` `<Array<OptionValue>>` — a list of option values, that represented as objects with two fields
|
||||
* `name` `<String>` — A human-readable option name ("80 MHz")
|
||||
* `value` `<String>` — A value, that will be used by tools. ("80")
|
||||
|
||||
### AvailableBoard
|
||||
- `name` `<String>` — A board name (e.g., "Arduino/Genuino Mega2560")
|
||||
- `package` `<String>` — A package and architecture, that could be used in the `core.install` command.
|
||||
For example, `arduino:avr`
|
||||
- `packageName` `<String>` — A human-readable architecture name. Like "Arduino AVR Boards"
|
||||
- `version` `<String>` — A Semver of the latest architecture for this board (e.g., `1.6.21`)
|
||||
|
||||
* `name` `<String>` — A board name (e.g., "Arduino/Genuino Mega2560")
|
||||
* `package` `<String>` — A package and architecture, that could be used in the `core.install` command. For example, `arduino:avr`
|
||||
* `packageName` `<String>` — A human-readable architecture name. Like "Arduino AVR Boards"
|
||||
* `version` `<String>` — A Semver of the latest architecture for this board (e.g., `1.6.21`)
|
||||
|
||||
### ProgressData
|
||||
- `message` `<String>` — A progress message from stdout of the `arduino-cli`.
|
||||
In case that there is a downloading process that shows progress bar, it will be
|
||||
`null`, because this type of progress should notify only about a percentage.
|
||||
- `percentage` `<Number>` — A number in the range [0.00...100.00]
|
||||
- `estimated` `<String>` — An estimated time in the format `3m52s` or `unknown`
|
||||
|
||||
* `message` `<String>` — A progress message from stdout of the `arduino-cli`. In case that there is a downloading process that shows progress bar, it will be `null`, because this type of progress should notify only about a percentage.
|
||||
* `percentage` `<Number>` — A number in the range [0.00...100.00]
|
||||
* `estimated` `<String>` — An estimated time in the format `3m52s` or `unknown`
|
||||
|
||||
### InstalledPackages
|
||||
- `ID` `<String>` — A package identifier in format `package:architecture` (e.g., `arduino:avr`)
|
||||
- `Installed` `<String>` — A version of the installed package
|
||||
- `Latest` `<String>` — A version of the latest package
|
||||
- `Name` `<String>` — A human-readable name of the architecture
|
||||
|
||||
* `ID` `<String>` — A package identifier in format `package:architecture` (e.g., `arduino:avr`)
|
||||
* `Installed` `<String>` — A version of the installed package
|
||||
* `Latest` `<String>` — A version of the latest package
|
||||
* `Name` `<String>` — A human-readable name of the architecture
|
||||
|
||||
### FoundPackages
|
||||
- `ID` `<String>` — A package identifier in format `package:architecture` (e.g., `arduino:avr`)
|
||||
- `Version` `<String>` — A version of the latest package
|
||||
- `Installed` `<String>` — Equals "Yes" if the package is installed, otherwise "No"
|
||||
- `Name` `<String>` — A name of the architecture
|
||||
|
||||
* `ID` `<String>` — A package identifier in format `package:architecture` (e.g., `arduino:avr`)
|
||||
* `Version` `<String>` — A version of the latest package
|
||||
* `Installed` `<String>` — Equals "Yes" if the package is installed, otherwise "No"
|
||||
* `Name` `<String>` — A name of the architecture
|
||||
|
||||
@@ -4,21 +4,22 @@ This package is a part of the [XOD](https://github.com/xodio/xod) project.
|
||||
|
||||
The package contains implemetation of `xodc` command line utility.
|
||||
|
||||
Basically it’s a collection of thin wrappers around NodeJS API’s available via
|
||||
other packages. The responsibility of `xod-cli` is to parse command line
|
||||
arguments, call API, and format the result on stdout/stderr properly.
|
||||
Basically it’s a collection of thin wrappers around NodeJS API’s available via other packages. The responsibility of `xod-cli` is to parse command line arguments, call API, and format the result on stdout/stderr properly.
|
||||
|
||||
`xodc` uses subcommands like `git` does to perform various functions.
|
||||
The subcommands handling could be found in `src/commands/*.js`.
|
||||
`xodc` uses subcommands like `git` does to perform various functions. The subcommands handling could be found in `src/commands/*.js`.
|
||||
|
||||
<!-- toc -->
|
||||
|
||||
* [xod-cli](#xod-cli)
|
||||
* [Usage](#usage)
|
||||
* [Flags, aliases, environment variables](#flags-aliases-environment-variables)
|
||||
* [Commands](#commands)
|
||||
<!-- tocstop -->
|
||||
<!-- tocstop -->
|
||||
|
||||
# Usage
|
||||
|
||||
<!-- usage -->
|
||||
|
||||
```sh-session
|
||||
$ npm install -g xod-cli
|
||||
$ xodc COMMAND
|
||||
@@ -30,15 +31,15 @@ USAGE
|
||||
$ xodc COMMAND
|
||||
...
|
||||
```
|
||||
|
||||
<!-- usagestop -->
|
||||
|
||||
# Flags, aliases, environment variables
|
||||
|
||||
Almost any flag can be replaced with the appropriate environment variable.
|
||||
For example, instead of `--username` you can declare variable `XOD_USERNAME`.
|
||||
Almost any flag can be replaced with the appropriate environment variable. For example, instead of `--username` you can declare variable `XOD_USERNAME`.
|
||||
|
||||
| Flag | Alias | Environment variable |
|
||||
|--------------|-------|----------------------|
|
||||
| ------------ | ----- | -------------------- |
|
||||
| --api | | XOD_API |
|
||||
| --board | -b | XOD_BOARD |
|
||||
| --debug | | XOD_DEBUG |
|
||||
@@ -50,9 +51,10 @@ For example, instead of `--username` you can declare variable `XOD_USERNAME`.
|
||||
| --username | | XOD_USERNAME |
|
||||
| --workspace | -w | XOD_WORKSPACE |
|
||||
|
||||
|
||||
# Commands
|
||||
|
||||
<!-- commands -->
|
||||
|
||||
* [`xodc autocomplete [SHELL]`](#xodc-autocomplete-shell)
|
||||
* [`xodc boards [options]`](#xodc-boards-options)
|
||||
* [`xodc compile [options] [entrypoint]`](#xodc-compile-options-entrypoint)
|
||||
@@ -372,4 +374,5 @@ EXAMPLE
|
||||
```
|
||||
|
||||
_See code: [src/commands/upload.js](https://github.com/xodio/xod/blob/master/packages/xod-cli/src/commands/upload.js)_
|
||||
|
||||
<!-- commandsstop -->
|
||||
|
||||
@@ -2,6 +2,4 @@
|
||||
|
||||
This package is a part of the [XOD](https://github.com/xodio/xod) project.
|
||||
|
||||
The package is a thin wrapper around
|
||||
[`xod-client`](https://github.com/xodio/xod/tree/master/packages/xod-client)
|
||||
which lifts it to a ready-to-use browser based XOD IDE.
|
||||
The package is a thin wrapper around [`xod-client`](https://github.com/xodio/xod/tree/master/packages/xod-client) which lifts it to a ready-to-use browser based XOD IDE.
|
||||
|
||||
@@ -2,9 +2,7 @@
|
||||
|
||||
This package is a part of the [XOD](https://github.com/xodio/xod) project.
|
||||
|
||||
The package is a thin wrapper around
|
||||
[`xod-client`](https://github.com/xodio/xod/tree/master/packages/xod-client)
|
||||
which lifts it to a ready-to-use desktop based XOD IDE.
|
||||
The package is a thin wrapper around [`xod-client`](https://github.com/xodio/xod/tree/master/packages/xod-client) which lifts it to a ready-to-use desktop based XOD IDE.
|
||||
|
||||
It is based on [Electron](https://electron.atom.io/).
|
||||
|
||||
@@ -18,24 +16,17 @@ For `electron-builder` we have to provide option:
|
||||
"buildDependenciesFromSource": true
|
||||
```
|
||||
|
||||
to properly build `serialport` native package when creating distributives.
|
||||
Otherwise it would be compiled against wrong version of Node ABI. Following
|
||||
issues have to be solved before we could drop the option:
|
||||
to properly build `serialport` native package when creating distributives. Otherwise it would be compiled against wrong version of Node ABI. Following issues have to be solved before we could drop the option:
|
||||
|
||||
- https://github.com/EmergingTechnologyAdvisors/node-serialport/issues/1180
|
||||
- https://github.com/EmergingTechnologyAdvisors/node-serialport/issues/1263
|
||||
* https://github.com/EmergingTechnologyAdvisors/node-serialport/issues/1180
|
||||
* https://github.com/EmergingTechnologyAdvisors/node-serialport/issues/1263
|
||||
|
||||
### Dedicate dist directory to electron-builder
|
||||
|
||||
All other packages use `dist/` as a target of transpilation,
|
||||
`xod-client-electron` is not because `dist` name used to be reserved for
|
||||
distro packaging. It uses `src-babel/` as a target for transpilation.
|
||||
All other packages use `dist/` as a target of transpilation, `xod-client-electron` is not because `dist` name used to be reserved for distro packaging. It uses `src-babel/` as a target for transpilation.
|
||||
|
||||
It have to be fixed since now `electron-builder` supports `directories/output`
|
||||
option.
|
||||
It have to be fixed since now `electron-builder` supports `directories/output` option.
|
||||
|
||||
### `electron-builder` support for lerna + yarn-workspaces monorepos
|
||||
|
||||
For now the [official support](https://github.com/electron-userland/electron-builder/issues/2205) is a bit broken, so in the meantime we use [our own fork](https://github.com/xodio/electron-builder/tree/look-for-node_modules-until-root)
|
||||
|
||||
|
||||
|
||||
@@ -2,42 +2,28 @@
|
||||
|
||||
This package is a part of the [XOD](https://github.com/xodio/xod) project.
|
||||
|
||||
The package contains the most of code related to the XOD IDE user interface.
|
||||
`xod-client` is build on React + Redux stack.
|
||||
The package contains the most of code related to the XOD IDE user interface. `xod-client` is build on React + Redux stack.
|
||||
|
||||
`xod-client` is neutral to platform. That means it doesn’t contain code
|
||||
specific to a particular execution environment like browser or electron.
|
||||
`xod-client` is neutral to platform. That means it doesn’t contain code specific to a particular execution environment like browser or electron.
|
||||
|
||||
To make it alive a bootstrapping wrapper is required that would embed the
|
||||
`xod-client` in a platform specific container. See
|
||||
[`xod-client-browser`](https://github.com/xodio/xod/tree/master/packages/xod-client-browser)
|
||||
[`xod-client-electron`](https://github.com/xodio/xod/tree/master/packages/xod-client-electron)
|
||||
for example.
|
||||
To make it alive a bootstrapping wrapper is required that would embed the `xod-client` in a platform specific container. See [`xod-client-browser`](https://github.com/xodio/xod/tree/master/packages/xod-client-browser) [`xod-client-electron`](https://github.com/xodio/xod/tree/master/packages/xod-client-electron) for example.
|
||||
|
||||
## Source code structure
|
||||
|
||||
The source is split into pods. Each pod is a part of whole application
|
||||
which implements a single aspect of the IDE.
|
||||
The source is split into pods. Each pod is a part of whole application which implements a single aspect of the IDE.
|
||||
|
||||
Each pod could contain:
|
||||
|
||||
- `components/` — [dumb](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0) React components
|
||||
- `containers/` — [smart](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0) React components
|
||||
- `actions.js` — Redux action dispatchers
|
||||
- `actionTypes.js` — name symbols for Redux actions
|
||||
- `reducer.js` — Redux reducer that operates on a pod’s state subtree
|
||||
- `selectors.js` — functions to query presentational data from state subtree (see below)
|
||||
- `state.js` — initial state for the pod’s subtree
|
||||
* `components/` — [dumb](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0) React components
|
||||
* `containers/` — [smart](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0) React components
|
||||
* `actions.js` — Redux action dispatchers
|
||||
* `actionTypes.js` — name symbols for Redux actions
|
||||
* `reducer.js` — Redux reducer that operates on a pod’s state subtree
|
||||
* `selectors.js` — functions to query presentational data from state subtree (see below)
|
||||
* `state.js` — initial state for the pod’s subtree
|
||||
|
||||
To work with XOD project state a separate package
|
||||
[`xod-project`](https://github.com/xodio/xod/tree/master/packages/xod-project)
|
||||
is used. Reducers simply delegate state update to `xod-project`’s functions,
|
||||
selectors, and components use functions from `xod-project` to access project
|
||||
data. This distincion is done because project state is complex and keeping all
|
||||
machinery inside standard pod layout would make it messy.
|
||||
To work with XOD project state a separate package [`xod-project`](https://github.com/xodio/xod/tree/master/packages/xod-project) is used. Reducers simply delegate state update to `xod-project`’s functions, selectors, and components use functions from `xod-project` to access project data. This distincion is done because project state is complex and keeping all machinery inside standard pod layout would make it messy.
|
||||
|
||||
## Environment variables
|
||||
|
||||
- **`XOD_HOSTNAME`**
|
||||
|
||||
XOD hostname. Default: `xod.io`
|
||||
* **`XOD_HOSTNAME`** XOD hostname. Default: `xod.io`
|
||||
|
||||
@@ -1,16 +1,13 @@
|
||||
# xod-deploy
|
||||
|
||||
This package is a part of the [XOD](https://github.com/xodio/xod) project.
|
||||
|
||||
The package provides cloud compilation feature.
|
||||
|
||||
## Development
|
||||
This package uses web socket server to compile code and http server to get upload
|
||||
config for boards. It uses a default URLs, that coded in the constants, but for
|
||||
better development experience it could be changed by environment variables.
|
||||
|
||||
- **XOD_CLOUD_UPLOAD_CONFIG_URL** — URL, that returns upload config for a board.
|
||||
Board identifier is appended at the end of the url, so
|
||||
`https://compile.xod.io/upload/` will be used like `https://compile.xod.io/upload/uno`
|
||||
This package uses web socket server to compile code and http server to get upload config for boards. It uses a default URLs, that coded in the constants, but for better development experience it could be changed by environment variables.
|
||||
|
||||
- **XOD_CLOUD_COMPILE_URL** — URL for web socket server.
|
||||
E.G. `wss://compile.xod.io/compile`
|
||||
* **XOD_CLOUD_UPLOAD_CONFIG_URL** — URL, that returns upload config for a board. Board identifier is appended at the end of the url, so `https://compile.xod.io/upload/` will be used like `https://compile.xod.io/upload/uno`
|
||||
|
||||
* **XOD_CLOUD_COMPILE_URL** — URL for web socket server. E.G. `wss://compile.xod.io/compile`
|
||||
|
||||
@@ -2,11 +2,6 @@
|
||||
|
||||
This package is a part of the [XOD](https://github.com/xodio/xod) project.
|
||||
|
||||
The package provides API to work with workspaces, libraries and projects
|
||||
that are stored as different files on the file system. It lets converting
|
||||
between normal (split files), xodball (single project monolith), and RAM
|
||||
representation.
|
||||
The package provides API to work with workspaces, libraries and projects that are stored as different files on the file system. It lets converting between normal (split files), xodball (single project monolith), and RAM representation.
|
||||
|
||||
Since it requires access to file system `xod-fs` is used by `xod-cli` and
|
||||
`xod-client-electron` packages. It is not used by `xod-client-browser`
|
||||
because a browser has no full access to user’s file system.
|
||||
Since it requires access to file system `xod-fs` is used by `xod-cli` and `xod-client-electron` packages. It is not used by `xod-client-browser` because a browser has no full access to user’s file system.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Hello world!
|
||||
|
||||
- It's a test file
|
||||
- If you see a correct content — it passed!
|
||||
- Also it could contain any UTF-8 characters, like this one 😎 or even кириллица!
|
||||
* It's a test file
|
||||
* If you see a correct content — it passed!
|
||||
* Also it could contain any UTF-8 characters, like this one 😎 or even кириллица!
|
||||
|
||||
Have a nice day!
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Hello world!
|
||||
|
||||
- It's a test file
|
||||
- If you see a correct content — it passed!
|
||||
- Also it could contain any UTF-8 characters, like this one 😎 or even кириллица!
|
||||
* It's a test file
|
||||
* If you see a correct content — it passed!
|
||||
* Also it could contain any UTF-8 characters, like this one 😎 or even кириллица!
|
||||
|
||||
Have a nice day!
|
||||
|
||||
@@ -2,6 +2,4 @@
|
||||
|
||||
This package is a part of the [XOD](https://github.com/xodio/xod) project.
|
||||
|
||||
The package provides utility functions to facilitate functional programming
|
||||
style used across the XOD project packages and complement libraries like
|
||||
Ramda and Ramda Fantasy.
|
||||
The package provides utility functions to facilitate functional programming style used across the XOD project packages and complement libraries like Ramda and Ramda Fantasy.
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
# xod-pm
|
||||
|
||||
This package is a part of the [XOD](https://github.com/xodio/xod) project.
|
||||
|
||||
The package provides API for cloud project and library management.
|
||||
|
||||
@@ -2,8 +2,6 @@
|
||||
|
||||
This package is a part of the [XOD](https://github.com/xodio/xod) project.
|
||||
|
||||
The package provides API to query and update XOD projects’ state: create
|
||||
and delete nodes and links, manage patches, validate state shape, etc.
|
||||
The package provides API to query and update XOD projects’ state: create and delete nodes and links, manage patches, validate state shape, etc.
|
||||
|
||||
The API is done in
|
||||
[functional style](https://github.com/xodio/xod/wiki/Style-Guide#functional-style-programming).
|
||||
The API is done in [functional style](https://github.com/xodio/xod/wiki/Style-Guide#functional-style-programming).
|
||||
|
||||
@@ -1,15 +1,10 @@
|
||||
# xod-tabtest
|
||||
|
||||
The package implements tabular test features for XOD patches. A patch may
|
||||
include a `patch.test.tsv` spreadsheet file which defines several “input and
|
||||
expected output” lines.
|
||||
The package implements tabular test features for XOD patches. A patch may include a `patch.test.tsv` spreadsheet file which defines several “input and expected output” lines.
|
||||
|
||||
Using that data the package can generate a C++ test suite based on
|
||||
[Catch2](https://github.com/catchorg/catch2/) framework which can be compiled
|
||||
then with a regular GCC and run.
|
||||
Using that data the package can generate a C++ test suite based on [Catch2](https://github.com/catchorg/catch2/) framework which can be compiled then with a regular GCC and run.
|
||||
|
||||
The package does not depend on any Node.js functionality, so may be consumed
|
||||
from browser IDE, desktop IDE, or CLI.
|
||||
The package does not depend on any Node.js functionality, so may be consumed from browser IDE, desktop IDE, or CLI.
|
||||
|
||||
## File structure
|
||||
|
||||
|
||||
@@ -1,11 +1,10 @@
|
||||
[xod-jetbrains-live-template.jar](xod-jetbrains-live-template.jar) contains
|
||||
[Jetbrains' Live Template](https://www.jetbrains.com/help/idea/2016.3/live-templates.html)
|
||||
which helps XOD contributors to:
|
||||
- [create a topic branch](../../CONTRIBUTING.md#creating-a-topic-branch).
|
||||
- [create a commit message](../../CONTRIBUTING.md#performing-commits),
|
||||
[xod-jetbrains-live-template.jar](xod-jetbrains-live-template.jar) contains [Jetbrains' Live Template](https://www.jetbrains.com/help/idea/2016.3/live-templates.html) which helps XOD contributors to:
|
||||
|
||||
* [create a topic branch](../../CONTRIBUTING.md#creating-a-topic-branch).
|
||||
* [create a commit message](../../CONTRIBUTING.md#performing-commits),
|
||||
|
||||
To use it:
|
||||
- [import](https://www.jetbrains.com/help/idea/2016.3/sharing-live-templates.html#d894726e77) it
|
||||
into your Jetbrains IDE,
|
||||
- copy the issue's title to a clipboard (`ctrl+c`, serves as a data source),
|
||||
- type `xodc` to activate the template.
|
||||
|
||||
* [import](https://www.jetbrains.com/help/idea/2016.3/sharing-live-templates.html#d894726e77) it into your Jetbrains IDE,
|
||||
* copy the issue's title to a clipboard (`ctrl+c`, serves as a data source),
|
||||
* type `xodc` to activate the template.
|
||||
|
||||
37
workspace/__ardulib__/Ethernet2/README.md
vendored
37
workspace/__ardulib__/Ethernet2/README.md
vendored
@@ -1,42 +1,25 @@
|
||||
Ethernet "2" Library for Arduino
|
||||
================================
|
||||
# Ethernet "2" Library for Arduino
|
||||
|
||||
This Arduino library is for shields that use the **Wiznet [W5500]** chipset only.
|
||||
It does **not** work with other chipsets, such as the original Arduino Ethernet shield which
|
||||
uses the Wiznet [W5100] chipset.
|
||||
This Arduino library is for shields that use the **Wiznet [W5500]** chipset only. It does **not** work with other chipsets, such as the original Arduino Ethernet shield which uses the Wiznet [W5100] chipset.
|
||||
|
||||
For more information about this library please visit us at:
|
||||
http://www.arduino.cc/en/Reference/Ethernet
|
||||
For more information about this library please visit us at: http://www.arduino.cc/en/Reference/Ethernet
|
||||
|
||||
|
||||
W5500 Shields
|
||||
-------------
|
||||
## W5500 Shields
|
||||
|
||||
* [Adafruit W5500 Ethernet Shield](https://www.adafruit.com/products/2971)
|
||||
* [Arduino Ethernet Shield v2](https://www.arduino.cc/en/Main/ArduinoEthernetShieldV2)
|
||||
* [Industruino Ethernet module](https://industruino.com/shop/product/ethernet-expansion-module-10)
|
||||
* [Wiznet W5500 Ethernet Shield](http://www.wiznet.co.kr/product-item/w5500-ethernet-shield/)
|
||||
|
||||
|
||||
License
|
||||
-------
|
||||
## License
|
||||
|
||||
Copyright (c) 2009-2016 Arduino LLC. All right reserved.
|
||||
|
||||
This library is free software; you can redistribute it and/or
|
||||
modify it under the terms of the GNU Lesser General Public
|
||||
License as published by the Free Software Foundation; either
|
||||
version 2.1 of the License, or (at your option) any later version.
|
||||
This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.
|
||||
|
||||
This library 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
|
||||
Lesser General Public License for more details.
|
||||
This library 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 Lesser General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU Lesser General Public
|
||||
License along with this library; if not, write to the Free Software
|
||||
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
|
||||
You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
|
||||
|
||||
|
||||
[W5100]: http://www.wiznet.co.kr/product-item/w5100/
|
||||
[W5500]: http://www.wiznet.co.kr/product-item/w5500/
|
||||
[w5100]: http://www.wiznet.co.kr/product-item/w5100/
|
||||
[w5500]: http://www.wiznet.co.kr/product-item/w5500/
|
||||
|
||||
@@ -1,9 +1,11 @@
|
||||
# Installation #
|
||||
Create a new folder called "LiquidCrystal_I2C" under the folder named "libraries" in your Arduino sketchbook folder.
|
||||
Create the folder "libraries" in case it does not exist yet. Place all the files in the "LiquidCrystal_I2C" folder.
|
||||
# Installation
|
||||
|
||||
# Usage #
|
||||
To use the library in your own sketch, select it from *Sketch > Import Library*.
|
||||
Create a new folder called "LiquidCrystal_I2C" under the folder named "libraries" in your Arduino sketchbook folder. Create the folder "libraries" in case it does not exist yet. Place all the files in the "LiquidCrystal_I2C" folder.
|
||||
|
||||
-------------------------------------------------------------------------------------------------------------------
|
||||
This library is based on work done by DFROBOT (www.dfrobot.com).
|
||||
# Usage
|
||||
|
||||
To use the library in your own sketch, select it from _Sketch > Import Library_.
|
||||
|
||||
---
|
||||
|
||||
This library is based on work done by DFROBOT (www.dfrobot.com).
|
||||
|
||||
13
workspace/__ardulib__/README.md
vendored
13
workspace/__ardulib__/README.md
vendored
@@ -1,15 +1,10 @@
|
||||
# Arduino libraries
|
||||
|
||||
Arduino libraries
|
||||
=================
|
||||
|
||||
The directory contains vendoring copies of some Arduino Libraries used in
|
||||
native nodes’ implementations.
|
||||
The directory contains vendoring copies of some Arduino Libraries used in native nodes’ implementations.
|
||||
|
||||
* `LiquidCrystal` -- the standard library
|
||||
* `LiquidCrystal_I2C` -- https://github.com/fdebrabander/Arduino-LiquidCrystal-I2C-library
|
||||
* `SD` -- the standard library
|
||||
* `Servo` -- the standard library
|
||||
* `Ethernet2` -- https://github.com/xodio/Ethernet2 (modified https://github.com/adafruit/Ethernet2)
|
||||
* `ESP8266UART` -- custom library. Should be published to the XOD GitHub repository
|
||||
along with the "UART" library, which is bundled into `xod-arduino/platform`
|
||||
and some `xod/uart` nodes.
|
||||
* `Ethernet2` -- https://github.com/xodio/Ethernet2 (modified https://github.com/adafruit/Ethernet2)
|
||||
* `ESP8266UART` -- custom library. Should be published to the XOD GitHub repository along with the "UART" library, which is bundled into `xod-arduino/platform` and some `xod/uart` nodes.
|
||||
|
||||
Reference in New Issue
Block a user