Modernize build, Platform Parity #112
Conversation
Dependencies with modified semantic versioning:
@commitlint/cliAuthor: Mario Nebl Description: Lint your commit messages Homepage: https://github.com/conventional-changelog/commitlint#readme
|
| Created | about 2 years ago |
| Last Updated | about 1 month ago |
| License | MIT |
| Maintainers | 4 |
| Releases | 27 |
| Direct Dependencies | conventional-changelog-conventionalcommits |
| Keywords | conventional-changelog, commitlint, commitlint-config and angular |
README
Lint your conventional commits
@commitlint/config-conventional
Shareable commitlint config enforcing conventional commits.
Use with @commitlint/cli and @commitlint/prompt-cli.
| IMPORTANT | This is a direct replacement for @commitlint/config-angular prior to version 4. config-angular diverged from the conventional commit convention as of version 5. See #146 for details. |
Getting started
npm install --save-dev @commitlint/config-conventional @commitlint/cli
echo "module.exports = {extends: ['@commitlint/config-conventional']};" > commitlint.config.jsRules
Problems
The following rules are considered problems for @commitlint/config-conventional and will yield a non-zero exit code when not met.
Consult docs/rules for a list of available rules.
type-enum
-
condition:
typeis found in value -
rule:
always -
value
[ 'build', 'ci', 'chore', 'docs', 'feat', 'fix', 'perf', 'refactor', 'revert', 'style', 'test' ]
echo "foo: some message" # fails
echo "fix: some message" # passestype-case
- description:
typeis in casevalue - rule:
always - value
'lowerCase'
echo "FIX: some message" # fails
echo "fix: some message" # passestype-empty
- condition:
typeis empty - rule:
never
echo ": some message" # fails
echo "fix: some message" # passesscope-case
- condition:
scopeis in casevalue - rule:
always
'lowerCase'echo "fix(SCOPE): some message" # fails
echo "fix(scope): some message" # passessubject-case
- condition:
subjectis in one of the cases['sentence-case', 'start-case', 'pascal-case', 'upper-case'] - rule:
never
echo "fix(SCOPE): Some message" # fails
echo "fix(SCOPE): Some Message" # fails
echo "fix(SCOPE): SomeMessage" # fails
echo "fix(SCOPE): SOMEMESSAGE" # fails
echo "fix(scope): some message" # passes
echo "fix(scope): some Message" # passessubject-empty
- condition:
subjectis empty - rule:
never
echo "fix:" # fails
echo "fix: some message" # passessubject-full-stop
- condition:
subjectends withvalue - rule:
never - value
'.'echo "fix: some message." # fails
echo "fix: some message" # passesheader-max-length
- condition:
headerhasvalueor less characters - rule:
always - value
72echo "fix: some message that is way too long and breaks the line max-length by several characters" # fails
echo "fix: some message" # passes@seadub/clang-format-lint
Author: Christopher Williams
Description: Validate and/or fix formatting of files via clang-format
Homepage: https://github.com/sgtcoolguy/clang-format-lint#readme
| Created | 4 months ago |
| Last Updated | 4 months ago |
| License | MIT |
| Maintainers | 1 |
| Releases | 2 |
| Direct Dependencies | commander, glob and p-limit |
| Keywords | clang, clang-format and lint |
README
clang-format-lint
A very simple wrapper around the clang-format npm package/binary.
Intended to be used to either validate existing files, or automatically fix the formatting on them.
Usage:
npx clang-format-lint [--fix] [--exec-limit [limit]] glob[ glob]*e.g. To check if your source files match your formatting rules:
npx clang-format-lint android/src/**/*.javae.g. To ensure your source files match your formatting rules:
npx clang-format-lint --fix android/src/**/*.javaNew dependencies added: @commitlint/cli, @commitlint/config-conventional, @seadub/clang-format-lint, clang-format, commitizen, fs-extra, husky, lint-staged and titanium-docgen.
commitizen
Author: Jim Cummins
Description: Git commit, but play nice with conventions.
Homepage: https://github.com/commitizen/cz-cli
| Created | almost 5 years ago |
| Last Updated | 7 months ago |
| License | MIT |
| Maintainers | 5 |
| Releases | 64 |
| Direct Dependencies | cachedir, cz-conventional-changelog, dedent, detect-indent, find-node-modules, find-root, fs-extra, glob, inquirer, is-utf8, lodash, minimist, shelljs, strip-bom and strip-json-comments |
| Keywords | commit, pretty, format, conventional changelog and commitizen |
fs-extra
Author: JP Richardson
Description: fs-extra contains methods that aren't included in the vanilla Node.js fs package. Such as mkdir -p, cp -r, and rm -rf.
Homepage: https://github.com/jprichardson/node-fs-extra
| Created | about 8 years ago |
| Last Updated | 16 days ago |
| License | MIT |
| Maintainers | 3 |
| Releases | 86 |
| Direct Dependencies | graceful-fs, jsonfile and universalify |
| Keywords | fs, file, file system, copy, directory, extra, mkdirp, mkdir, mkdirs, recursive, json, read, write, extra, delete, remove, touch, create, text, output and move |
README
Node.js: fs-extra
fs-extra adds file system methods that aren't included in the native fs module and adds promise support to the fs methods. It also uses graceful-fs to prevent EMFILE errors. It should be a drop in replacement for fs.
Why?
I got tired of including mkdirp, rimraf, and ncp in most of my projects.
Installation
npm install fs-extra
Usage
fs-extra is a drop in replacement for native fs. All methods in fs are attached to fs-extra. All fs methods return promises if the callback isn't passed.
You don't ever need to include the original fs module again:
const fs = require('fs') // this is no longer necessaryyou can now do this:
const fs = require('fs-extra')or if you prefer to make it clear that you're using fs-extra and not fs, you may want
to name your fs variable fse like so:
const fse = require('fs-extra')you can also keep both, but it's redundant:
const fs = require('fs')
const fse = require('fs-extra')Sync vs Async vs Async/Await
Most methods are async by default. All async methods will return a promise if the callback isn't passed.
Sync methods on the other hand will throw if an error occurs.
Also Async/Await will throw an error if one occurs.
Example:
const fs = require('fs-extra')
// Async with promises:
fs.copy('/tmp/myfile', '/tmp/mynewfile')
.then(() => console.log('success!'))
.catch(err => console.error(err))
// Async with callbacks:
fs.copy('/tmp/myfile', '/tmp/mynewfile', err => {
if (err) return console.error(err)
console.log('success!')
})
// Sync:
try {
fs.copySync('/tmp/myfile', '/tmp/mynewfile')
console.log('success!')
} catch (err) {
console.error(err)
}
// Async/Await:
async function copyFiles () {
try {
await fs.copy('/tmp/myfile', '/tmp/mynewfile')
console.log('success!')
} catch (err) {
console.error(err)
}
}
copyFiles()Methods
Async
- copy
- emptyDir
- ensureFile
- ensureDir
- ensureLink
- ensureSymlink
- mkdirp
- mkdirs
- move
- outputFile
- outputJson
- pathExists
- readJson
- remove
- writeJson
Sync
- copySync
- emptyDirSync
- ensureFileSync
- ensureDirSync
- ensureLinkSync
- ensureSymlinkSync
- mkdirpSync
- mkdirsSync
- moveSync
- outputFileSync
- outputJsonSync
- pathExistsSync
- readJsonSync
- removeSync
- writeJsonSync
NOTE: You can still use the native Node.js methods. They are promisified and copied over to fs-extra. See notes on fs.read() & fs.write()
What happened to walk() and walkSync()?
They were removed from fs-extra in v2.0.0. If you need the functionality, walk and walkSync are available as separate packages, klaw and klaw-sync.
Third Party
TypeScript
If you like TypeScript, you can use fs-extra with it: https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/fs-extra
File / Directory Watching
If you want to watch for changes to files or directories, then you should use chokidar.
Obtain Filesystem (Devices, Partitions) Information
fs-filesystem allows you to read the state of the filesystem of the host on which it is run. It returns information about both the devices and the partitions (volumes) of the system.
Misc.
- fs-extra-debug - Send your fs-extra calls to debug.
- mfs - Monitor your fs-extra calls.
Hacking on fs-extra
Wanna hack on fs-extra? Great! Your help is needed! fs-extra is one of the most depended upon Node.js packages. This project
uses JavaScript Standard Style - if the name or style choices bother you,
you're gonna have to get over it :) If standard is good enough for npm, it's good enough for fs-extra.
What's needed?
- First, take a look at existing issues. Those are probably going to be where the priority lies.
- More tests for edge cases. Specifically on different platforms. There can never be enough tests.
- Improve test coverage. See coveralls output for more info.
Note: If you make any big changes, you should definitely file an issue for discussion first.
Running the Test Suite
fs-extra contains hundreds of tests.
npm run lint: runs the linter (standard)npm run unit: runs the unit testsnpm test: runs both the linter and the tests
Windows
If you run the tests on the Windows and receive a lot of symbolic link EPERM permission errors, it's
because on Windows you need elevated privilege to create symbolic links. You can add this to your Windows's
account by following the instructions here: http://superuser.com/questions/104845/permission-to-make-symbolic-links-in-windows-7
However, I didn't have much luck doing this.
Since I develop on Mac OS X, I use VMWare Fusion for Windows testing. I create a shared folder that I map to a drive on Windows.
I open the Node.js command prompt and run as Administrator. I then map the network drive running the following command:
net use z: "\\vmware-host\Shared Folders"
I can then navigate to my fs-extra directory and run the tests.
Naming
I put a lot of thought into the naming of these functions. Inspired by @coolaj86's request. So he deserves much of the credit for raising the issue. See discussion(s) here:
- Merge with fs.extra and mkdirp jprichardson/node-fs-extra#2
- other fs modules to merge in flatiron/utile#11
- join forces with fs.extra, fs-extra, and others? ryanmcgrath/wrench-js#29
- https://github.com/substack/node-mkdirp/issues/17
First, I believe that in as many cases as possible, the Node.js naming schemes should be chosen. However, there are problems with the Node.js own naming schemes.
For example, fs.readFile() and fs.readdir(): the F is capitalized in File and the d is not capitalized in dir. Perhaps a bit pedantic, but they should still be consistent. Also, Node.js has chosen a lot of POSIX naming schemes, which I believe is great. See: fs.mkdir(), fs.rmdir(), fs.chown(), etc.
We have a dilemma though. How do you consistently name methods that perform the following POSIX commands: cp, cp -r, mkdir -p, and rm -rf?
My perspective: when in doubt, err on the side of simplicity. A directory is just a hierarchical grouping of directories and files. Consider that for a moment. So when you want to copy it or remove it, in most cases you'll want to copy or remove all of its contents. When you want to create a directory, if the directory that it's suppose to be contained in does not exist, then in most cases you'll want to create that too.
So, if you want to remove a file or a directory regardless of whether it has contents, just call fs.remove(path). If you want to copy a file or a directory whether it has contents, just call fs.copy(source, destination). If you want to create a directory regardless of whether its parent directories exist, just call fs.mkdirs(path) or fs.mkdirp(path).
Credit
fs-extra wouldn't be possible without using the modules from the following authors:
License
Licensed under MIT
Copyright (c) 2011-2017 JP Richardson
husky
Author: Typicode
Description: Prevents bad commit or push (git hooks, pre-commit/precommit, pre-push/prepush, post-merge/postmerge and all that stuff...)
Homepage: https://github.com/typicode/husky#readme
| Created | over 5 years ago |
| Last Updated | 11 days ago |
| License | MIT |
| Maintainers | 1 |
| Releases | 150 |
| Direct Dependencies | chalk, ci-info, compare-versions, cosmiconfig, find-versions, opencollective-postinstall, pkg-dir, please-upgrade-node, slash and which-pm-runs |
| Keywords | git, hook, hooks, pre-commit, precommit, post-commit, postcommit, pre-push, prepush, post-merge, postmerge, test and lint |
lint-staged
Author: Andrey Okonetchnikov
Description: Lint files staged by git
Homepage: https://github.com/okonet/lint-staged#readme
| Created | about 4 years ago |
| Last Updated | 4 days ago |
| License | MIT |
| Maintainers | 1 |
| Releases | 139 |
| Direct Dependencies | chalk, commander, cosmiconfig, debug, dedent, execa, listr, log-symbols, micromatch, normalize-path, please-upgrade-node, string-argv and stringify-object |
| Keywords | lint, git, staged, eslint, prettier, stylelint, code, quality, check, format and validate |
titanium-docgen
Author: Axway Appcelerator
Description: Generates Titanium API documentation in different formats
Homepage: https://github.com/appcelerator/docs-devkit#readme
| Created | 6 months ago |
| Last Updated | about 2 months ago |
| License | Apache-2.0 |
| Maintainers | 1 |
| Releases | 10 |
| Direct Dependencies | colors, ejs, js-yaml, markdown-it and node-appc |
| Keywords | titanium, docgen, documentation and docs |
README
titanium-docgen
Generates Titanium API documentation in different formats
Installation
npm i titanium-docgen -DUsage
node docgen [--addon-docs <PATH_TO_YAML_FILES] [--css <CSS_FILE>] [--format <EXPORT_FORMAT>] [--output <OUTPUT_DIRECTORY>] <PATH_TO_YAML_FILES>For a description of each option. run docgen --help.
Supported formats
| Format | Description |
|---|---|
addon |
|
changes |
|
html |
HTML files for the official docs at https://docs.appcelerator.com |
jsca |
JSCA content assist metadata |
jsduck |
https://github.com/senchalabs/jsduck |
json |
JSON metadata file |
json-raw |
Same as json, but with no pre-rendered markdown |
modulehtml |
|
parity |
|
solr |
Solr search index |
typescript |
TypeScript type definition file |
clang-format
Author: Unknown
Description: node wrapper around clang-format
Homepage: https://github.com/angular/clang-format#readme
| Created | almost 5 years ago |
| Last Updated | 7 days ago |
| License | Apache-2.0 |
| Maintainers | 3 |
| Releases | 65 |
| Direct Dependencies | async, glob and resolve |
README
clang-format
node.js module which wraps the native clang-format executable.
From the command-line:
$ npm install -g clang-format
$ clang-format -help
If your platform isn't yet supported, you can create the native binary from
the latest upstream clang sources, make sure it is stripped and optimized
(should be about 1.4MB as of mid-2015) and send a pull request to add it.
Checking formatting
Ensuring that changes to your code are properly formatted is an important part
of your development workflow. Note that the check-clang-format and
git-clang-format commands require Python to be globally available.
We recommend using a git pre-commit hook. You can configure this as follows:
-
add a
precommitscript to your package.json file:"scripts": { "precommit": "check-clang-format" }
By default, the user gets an error instructing them to run
./node_modules/.bin/git-clang-format. You may find it more ergonomic to set
up a package.json script, eg.
"scripts": { "format": "git-clang-format" }In this case, add a second argument to the "precommit" script, giving the
error you'd like to print for users, eg."precommit": "check-clang-format \"yarn format\"" -
Add a devDependency on the
huskypackage, which will add a
.git/hooks/pre-commitscript, which in turn triggers theprecommit
package.json script to run whenever someone adds a commit in this repository:$ yarn add -D husky
or
npm install --save-dev husky
Why do this in a pre-commit hook? For one thing, it's faster to run
clang-formatonly on the changed files, especially as the repository grows.
Also, this lets you upgradeclang-formator change your settings without
needing to re-format the entire repository, while still enforcing that later
changes follow the new style.
Globbing files
$ clang-format --glob=folder/**/*.js
This will run clang-format once per file result, and show the total
formatted files at the end.
See node-glob for globbing semantics.
Compiling clang-format
For Linux, compile a statically linked MinSizeRel build:
cmake -G Ninja -DCMAKE_BUILD_TYPE=MinSizeRel -DLLVM_BUILD_STATIC=true ..
ninja clang-format
For Mac OS X, static linking is not required.
Windows
Windows snapshot builds to include in the release can be found at the
LLVM website.
Configure with:
cmake -G "Visual Studio 12" -DCMAKE_BUILD_TYPE=MinSizeRel ..
In the generated Visual Studio project, search for the clang-format binary in
the Solution Explorer window, right click and choose Build.
…se(), report formats as constant values not strings
|
@sgtcoolguy another option would be moving the Android part to https://firebase.google.com/docs/ml-kit/android/read-barcodes as a library. Not sure about the performance or other advantages. But it is supported by google so it might have a better support on phones |
|
Pushed changes to remove commented code. Tested the provided example on both Android and iOS. Barcodes scan fine. Merging. |
Description: