Fixes from @sokra's review of #29325
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes
## Feature
- [ ] Telemetry added. In case of a feature if it's used or not.
### Replace 'require' with 'import' in bench files
Node.js 12 allows you to use `import`.
### Update dependancies
https://github.com/jprichardson/node-fs-extra/blob/master/CHANGELOG.md#breaking-changes
> Require Node.js v12+
For #25761, Node.js 12 is required. Therefore, there is no problem updating it. For benchmarking purposes, it would be reasonable to update to the latest version.
A number of changes here. I recommend viewing the diff with the <a href="?w=1">whitespace flag enabled</a>.
- OpenTelemetry is replaced with a custom and lightweight tracing solution.
- Three trace targets are currently supported: console, Zipkin, and NextJS.
- Tracing is now governed by environment variables rather than `--require instrument.js`.
+ `TRACE_TARGET`: one of `CONSOLE`, `ZIPKIN`, or `TELEMETRY`; defaults to `TELEMETRY` if unset or invalid.
+ `TRACE_ID`: an 8-byte hex-encoded value used as the Zipkin trace ID; if not provided, this value will be randomly generated and passed down to subprocesses.
Other sundry:
- I'm missing something, probably a setup step, with the Zipkin target. Traces are captured successfully, but you have to manually enter the Trace ID in order to view the trace - it doesn't show up in queries.
- I'm generally unhappy with [this commit](235cedcb3e). It is... untidy to provide a telemetry object via `setGlobal`, but I don't have a ready alternative. Is `distDir` strictly required when creating a new Telemetry object? I didn't dig too deep here.
As noted, there are a lot of changes, so it'd be great if a reviewer could:
- [ ] pull down the branch and try to break it
- [ ] check the Zipkin traces and identify possible regressions in the functionality
Closes#22570Fixes#22574
@timneutkens this adds a trace capturing script alongside the other tracing sundry. This will be utilized by the performance automation. Additionally, its nice to have an option other than running the ZipKin JAR to get at the raw data.
* replace recursive-copy with own implementation
* update yarn.lock
* do not filter out not directories
* do not fail if folder already exists
* replace `\` by `/` when sending pathes to filter
* use fs-extra only in tests
* investigate and test recursive-copy npm module
* improve test by creating fixtures programmatically
* remove recursive-copy npm module test
* add recursive-copy to bench
* add bench:recursive-copy script
* fix Sema import in recursive-copy.ts
* small improvements
* Run prettier over packages/**/*.js
* Run prettier over packages/**/*.ts
* Run prettier over examples
* Remove tslint
* Run prettier over examples
* Run prettier over all markdown files
* Run prettier over json files
We don't use a lot of the features of `glob`, so let's remove it in favor of a leaner approach using regex.
It's failing on windows and I have no idea why and don't own a windows machine 🤦🏼♂️
(Ignore some of the commits in here, I forgot to create the new branch before I started working)