dd-trace 5.6.0 → 5.8.0

package/CONTRIBUTING.md

@@ -1,171 +0,0 @@
-# Contributing to dd-trace-js
-
-Please reach out before starting work on any major code changes.
-This will ensure we avoid duplicating work, or that your code can't be merged due to a rapidly changing
-base. If you would like support for a module that is not listed, [contact support][1] to share a request.
-
-## Keep changes small and incremental
-
-Changes should be incremental and understandable. As much as possible, large-scale efforts should be broken up into many PRs over time for better reviewability. If a feature would require more changes to be "complete" it's fine to land partial changes if they are not wired up to anything yet, so long as tests are included which at least prove those parts work in isolation.
-
-There are great benefits to taking a measured and iterative approach to improvement. When working on code in fewer places there is far less risk of running into merge conflicts or incompatibilities with other systems. Keeping contributions small makes them easy to review which makes that much quicker to land. Additionally, keeping things small and iterative makes it easier for other teams to review and understand what the code does.
-
-## Be descriptive
-
-Sometimes code can be self-documenting, but often it can't. That is especially true to someone reviewing code they haven't worked on. Be conscious of writing code in a self-describing way and leave comments anywhere that self-description fails. This goes a long way towards making even complex code coherent to one not already familiar with it.
-
-Try to write code in a way the describes the intent when read. For example, verbs can be used for function and method names to communicate that they are used to do some specific action. In doing so it becomes clear when referenced by name elsewhere that it is a function and what the function is meant to do. If a function can not be described with a simple verb it's probably too complex or does too many things.
-
-## Give your code space
-
-Very dense code is hard to read. It helps to make use of empty lines to separate logical groupings of statements. Long lines should be split up into multiple lines to make them more readable. Complex objects or arrays should generally be split over several lines. Sometimes it's a good idea to assign a variable only to immediately use it in a call as it can be more descriptive than just using the expression in place. It's not always clear what an argument is for if it doesn't visibly have a name somehow. Remember, lines are free, our time is not.
-
-## Avoid large refactors
-
-Large refactors should generally be avoided in favour of iterative approaches. For example, rather than rewriting how every plugin works, one might make a special-case plugin that works a bit different for their particular use-case. If several dozen files need to change to add a feature we've probably done something wrong.
-
-Sometimes new patterns or new ideas emerge which would be a substantial improvement over the existing state. It can be tempting to want to go all-in on a new way to do something, but the code churn can be hard to manage. It's best to introduce such new things incrementally and advocate for their adoption gradually through the rest of the codebase. As old systems are gradually phased out, the infrastructure which supports them can be deleted or relegated to lazy-loading only if and when that specific part of the system needs to be used.
-
-## Test everything
-
-It's very difficult to know if a change is valid unless there are tests to prove it. As an extension of that, it's also difficult to know the _use_ of that code is valid if the way it is integrated is not propertly tested. For this reason we generally favour integration tests over unit tests. If an API is expected to be used in different places or in different ways then it should generally include unit tests too for each unique scenario, however great care should be taken to ensure unit tests are actually testing the _logic_ and not just testing the _mocks_. It's a very common mistake to write a unit test that abstracts away the actual use of the interface so much that it doesn't actually test how that interface works in real-world scenarios. Remember to test how it handles failures, how it operates under heavy load, and how it impacts usability of what its purpose is.
-
-## Don't forget benchmarks
-
-Observability products tend to have quite a bit of their behaviour running in app code hot paths. It's important we extensively benchmark anything we expect to have heavy use to ensure it performs well and we don't cause any significant regressions through future changes. Measuring once at the time of writing is insufficient--a graph with just one data point is not going to tell you much of anything.
-
-## Always consider backportability
-
-To reduce delta between release lines and make it easier for us to support older versions we try as much as possible to backport every change we can. We should be diligent about keeping breaking changes to a minimum and ensuring we don't use language or runtime features which are too new. This way we can generally be confident that a change can be backported.
-
-To reduce the surface area of a breaking change, the breaking aspects could be placed behind a flag which is disabled by default or isolated to a function. In the next major the change would then be just to change the default of the flag or to start or stop calling the isolated function. By isolating the breaking logic it also becomes easier to delete later when it's no longer relevant on any release line.
-
-Currently we do not have CI to test PRs for mergeability to past release lines, but we intend to expand our CI to include that in the future. For the time being, it's recommended when developing locally to try to cherry-pick your changes onto the previous vN.x branches to see if the tests pass there too.
-
-## Respect semantic versioning
-
-This library follows the semantic versioning standard, but there are some subtleties left under-specified so this section is meant to clarify exactly how we interpret the meaning of semver. Additionally, it exists to communicate that we also use semver labels on all PRs to indicate which type of release the change should land in. Outside contributions should be evaluated and a semver label selected by the relevant team.
-
-### semver-patch
-
-If the change is a bug or security fix, it should be labelled as semver-patch. These changes should generally not alter existing behaviour in any way other than to correct the specific issue.
-
-### semver-minor
-
-Any addition of new functionality should be labelled as semver-minor and should not change any existing behaviour either in how any existing API works or in changing the contents or value of any existing data being reported except in purely additive cases where all existing data retains its prior state. Such changes may include new configuration options which when used will change behaviour, or may include the addition of new data being captured such as a new instrumentation, but should not impact the current operating design of any existing features.
-
-### semver-major
-
-In the event that some existing functionality _does_ need to change, as much as possible the non-breaking aspects of that change should be made in a semver-minor PR and the actually breaking aspects should be done via a follow-up PR with only the specific aspects which are breaking. Remember to [always consider backportability](#always-consider-backportability).
-
-## Indicate intended release targets
-
-When writing major changes we use a series of labels in the form of `dont-land-on-vN.x` where N is the major release line which a PR should not land in. Every PR marked as semver-major should include these tags. These tags allow our [branch-diff](https://github.com/bengl/branch-diff) tooling to work smoothly as we can exclude PRs not intended for the release line we're preparing a release proposal for. The `semver-major` labels on their own are not sufficient as they don't encode any indication of from _which_ releases they are a major change.
-
-For outside contributions we will have the relevant team add these labels when they review and determine when they plan to release it.
-
-## Ensure all tests are green
-
-We follow an all-green policy which means that for any PR to be merged _all_ tests must be passing. If a test is flaky or failing consistently the owner of that test should make it a priority to fix that test and unblock other teams from landing changes. For outside contributors there are currently several tests which will always fail as full CI permission is required. For these PRs our current process is for the relevant team to copy the PR and resubmit it to run tests as a user with full CI permission.
-
-Eventually we plan to look into putting these permission-required tests behind a label which team members can add to their PRs at creation to run the full CI and can add to outside contributor PRs to trigger the CI from their own user credentials. If the label is not present there will be another action which checks the label is present. Rather than showing a bunch of confusing failures to new contributors it would just show a single job failure which indicates an additional label is required, and we can name it in a way that makes it clear that it's not the responsibility of the outside contributor to add it. Something like `approve-full-ci` is one possible choice there.
-
-## Development Requirements
-
-Since this project supports multiple Node versions, using a version
-manager such as [nvm](https://github.com/creationix/nvm) is recommended.
-
-We use [yarn](https://yarnpkg.com/) for its workspace functionality, so make sure to install that as well.
-
-To install dependencies once you have Node and yarn installed, run:
-
-```sh
-$ yarn
-```
-
-
-## Testing
-
-Before running _plugin_ tests, the data stores need to be running.
-The easiest way to start all of them is to use the provided
-docker-compose configuration:
-
-```sh
-$ docker-compose up -d -V --remove-orphans --force-recreate
-$ yarn services
-```
-
-> **Note**
-> The `couchbase`, `grpc` and `oracledb` instrumentations rely on native modules
-> that do not compile on ARM64 devices (for example M1/M2 Mac) - their tests
-> cannot be run locally on these devices.
-
-### Unit Tests
-
-There are several types of unit tests, for various types of components. The
-following commands may be useful:
-
-```sh
-# Tracer core tests (i.e. testing `packages/dd-trace`)
-$ yarn test:trace:core
-# "Core" library tests (i.e. testing `packages/datadog-core`
-$ yarn test:core
-# Instrumentations tests (i.e. testing `packages/datadog-instrumentations`
-$ yarn test:instrumentations
-```
-
-Several other components have test commands as well. See `package.json` for
-details.
-
-To test _plugins_ (i.e. components in `packages/datadog-plugin-XXXX`
-directories, set the `PLUGINS` environment variable to the plugin you're
-interested in, and use `yarn test:plugins`. If you need to test multiple
-plugins you may separate then with a pipe (`|`) delimiter. Here's an
-example testing the `express` and `bluebird` plugins:
-
-```sh
-PLUGINS="express|bluebird" yarn test:plugins
-```
-
-
-### Memory Leaks
-
-To run the memory leak tests, use:
-
-```sh
-$ yarn leak:core
-
-# or
-
-$ yarn leak:plugins
-```
-
-
-### Linting
-
-We use [ESLint](https://eslint.org) to make sure that new code
-conforms to our coding standards.
-
-To run the linter, use:
-
-```sh
-$ yarn lint
-```
-
-
-### Benchmarks
-
-Our microbenchmarks live in `benchmark/sirun`. Each directory in there
-corresponds to a specific benchmark test and its variants, which are used to
-track regressions and improvements over time.
-
-In addition to those, when two or more approaches must be compared, please write
-a benchmark in the `benchmark/index.js` module so that we can keep track of the
-most efficient algorithm. To run your benchmark, use:
-
-```sh
-$ yarn bench
-```
-
-
-[1]: https://docs.datadoghq.com/help

package/MIGRATING.md

@@ -1,224 +0,0 @@
-# Migrating
-
-This guide describes the steps to upgrade dd-trace from a major version to the
-next. If you are having any issues related to migrating, please feel free to
-open an issue or contact our [support](https://www.datadoghq.com/support/) team.
-
-## 4.0 to 5.0
-
-### Node 16 is no longer supported
-
-Node.js 16 has reached EOL in September 2023 and is no longer supported. Generally
-speaking, we highly recommend always keeping Node.js up to date regardless of
-our support policy.
-
-### Update `trace<T>` TypeScript declaration
-
-The TypeScript declaration for `trace<T>` has been updated to enforce 
-that calls to `tracer.trace(name, fn)` must receive a function which takes at least 
-the span object. Previously the span was technically optional when it should not have 
-been as the span must be handled.
-
-## 3.0 to 4.0
-
-### Node 14 is no longer supported
-
-Node.js 14 has reached EOL in April 2023 and is no longer supported. Generally
-speaking, we highly recommend always keeping Node.js up to date regardless of
-our support policy.
-
-### The `orphanable` option was removed
-
-This option was only useful internally for a single integration that has since
-been removed. It was never useful for manual instrumentation since all that is
-needed to orphan a span on creation is to use
-`tracer.trace('web.request', { childOf: null })`.
-
-### Support for `jest-jasmine2` has been removed
-
-The default test runner for Jest was changed to `jest-circus` around 2 years ago and
-is no longer supported by our Jest integration for CI Visibility. We recommend
-switching to `jest-circus` to anyone still using `jest-jasmine2`.
-
-### Support for older Next.js versions was removed
-
-We now support only Next.js 10.2 and up.
-
-## 2.0 to 3.0
-
-### Node 12 is no longer supported
-
-Node.js 12 has been EOL since April 2022 and is no longer supported. Generally
-speaking, we highly recommend always keeping Node.js up to date regardless of our
-support policy.
-
-### HTTP query string reported by default
-
-HTTP query strings are now reported by default as part of the `http.url` tag.
-This change is considered breaking only because there might be sensitive data
-in the query string. A default regular expression based obfuscator is provided
-for common use cases like API keys, but if your use case is not covered, the
-[DD_TRACE_OBFUSCATION_QUERY_STRING_REGEXP](https://datadoghq.dev/dd-trace-js/#tracer-settings)
-environment variable can be used to control what is obfuscated, and a value of
-`.*` would redact the query string entirely.
-
-### HTTP operation name change
-
-The HTTP integration now uses `web.request` for incoming requests and continues
-to use `http.request` for outgoing requests. When using a supported web
-framework like Express, this change will have no effect because the root span
-would already have an operation name override like `express.request`.
-Any [monitor](https://docs.datadoghq.com/monitors/create/types/apm/?tab=apmmetrics)
-on `http.request` for incoming requests should be updated to `web.request`.
-
-With this change, both operation names also appear under the main service name
-and are no longer split between the server service name and a separate client
-service name suffixed with `-http-client`.
-
-### gRPC operation name change
-
-The gRPC integration now uses `grpc.server` for incoming requests and
-`grpc.client` for outgoing requests. Any
-[monitor](https://docs.datadoghq.com/monitors/create/types/apm/?tab=apmmetrics)
-on `grpc.request` should be updated to one of these.
-
-With this change, both operation names also appear under the main service name
-and are no longer split between the server service name and a separate client
-service name suffixed with `-http-client`.
-
-### Removal of `fs` integration
-
-The `fs` integration was removed as it was originally added without an actual
-use case, and it's been problematic ever since. It's noisy, the output is
-confusing when using streams, errors that are handled higher in the stack end up
-being captured, etc.
-
-If you had any use for file system instrumentation, please let us know so we can
-provide an alternative.
-
-### Scope binding for promises and event emitters
-
-It's no longer possible to bind promises using `tracer.scope().bind(promise)` or
-event emitters using `tracer.scope().bind(emitter)`. These were historically
-added mostly for internal use, and changes to context propagation over the years
-made them unnecessary, both internally and externaly. If one of these is used
-anywhere, the call will simply be ignored and no binding will occur.
-
-To bind the `then` handler of a promise, bind the function directly directly:
-
-```js
-promise.then(tracer.scope().bind(handler))
-```
-
-To bind all listeners for an event, wrap the call to `emit` directly instead:
-
-```js
-tracer.scope().activate(span, () => {
-  emitter.emit('event')
-})
-```
-
-To bind individual listeners, bind the listener function directly instead:
-
-```js
-emitter.on('event', tracer.scope().bind(listener, span))
-```
-
-### Removed APIs
-
-The following APIs have been deprecated for a long time and have now been
-completely removed:
-
-- `tracer.currentSpan()`
-- `tracer.bindEmitter()`
-
-Since these have not been recommended nor publicly documented for years at this
-point, there should be no impact as no application is expected to be using them.
-
-### CI Visibility new entrypoints
-
-#### Cypress
-
-`dd-trace/cypress/plugin` and `dd-trace/cypress/support` are removed, so you won't 
-be able to use them for your `cypress` instrumentation. Use `dd-trace/ci/cypress/plugin`
-and `dd-trace/ci/cypress/support` instead for your plugin and support configuration 
-respectively. 
-
-#### Jest
-
-The use of `'dd-trace/ci/jest/env'` in [`testEnvironment`](https://jestjs.io/docs/configuration#testenvironment-string)
-is no longer supported. 
-To instrument `jest` tests now, add `'-r dd-trace/ci/init'` to the `NODE_OPTIONS` environment
-variable passed to the process running the tests, for example, `NODE_OPTIONS='-r dd-trace/ci/init' yarn test`.
-
-#### Mocha
-
-The use of `--require dd-trace/ci/init` as a `mocha` flag is no longer supported. 
-To instrument `mocha` tests now, add `'-r dd-trace/ci/init'` to the `NODE_OPTIONS` environment
-variable passed to the process running the tests, for example, `NODE_OPTIONS='-r dd-trace/ci/init' yarn test`.
-
-#### Cucumber
-
-The use of `--require-module dd-trace/ci/init` as a `cucumber-js` flag is no longer supported.
-To instrument `cucumber-js` tests now, add `'-r dd-trace/ci/init'` to the `NODE_OPTIONS` environment
-variable passed to the process running the tests, for example, `NODE_OPTIONS='-r dd-trace/ci/init' yarn test`.
-
-## 1.0 to 2.0
-
-### Configuration
-
-The following configuraton options are no longer available programmatically and
-must be configured using these environment variables:
-
-* `enabled` -> `DD_TRACE_ENABLED=true|false`
-* `debug` -> `DD_TRACE_DEBUG=true|false`
-
-If environment variables were already used for these options, no action is
-needed.
-
-The following configuration options were completely removed and will no longer
-have any effect:
-
-* `scope`
-
-Startup logs are now disabled by default and can be enabled if needed with
-`DD_TRACE_STARTUP_LOGS=true`.
-
-### Removed APIs
-
-The original scope manager has been replaced several years ago and has now been
-removed. Any code referencing `tracer.scopeManager()` should be removed or
-replaced with `tracer.scope()` which is documented
-[here](https://datadoghq.dev/dd-trace-js/#scope-manager).
-
-### Nested objects as tags
-
-Support for nested objects as tags as been removed. When adding an object as a
-tag value, only properties that exist on that object directly will be added as
-tags. If nested properties are also needed, these should be added by hand.
-
-For example:
-
-```js
-const obj = {
-  a: 'foo',
-  b: {
-    c: 'bar'
-  }
-}
-
-// 1.0
-span.setTag('test', obj) // add test.a and test.b.c
-
-// 2.0
-span.setTag('test', obj) // add test.a
-span.setTag('test.b', obj.b) // add test.b.c
-```
-
-Arrays are no longer supported and must be converted to string manually.
-
-### Outgoing request filtering
-
-Outgoing request filtering is no longer supported and is now only available for
-incoming requests. This means that the `blocklist` and `allowlist` options on
-the `http` integration no longer have any effect.

package/packages/dd-trace/src/external-logger/test/index.spec.js

@@ -1,147 +0,0 @@
-'use strict'
-
-require('../../../../dd-trace/test/setup/tap')
-const proxyquire = require('proxyquire')
-const { expect } = require('chai')
-const nock = require('nock')
-
-const tracerLogger = require('../../log')
-
-describe('External Logger', () => {
-  let externalLogger
-  let interceptor
-  let errorLog
-
-  beforeEach(() => {
-    errorLog = sinon.spy(tracerLogger, 'error')
-
-    const { ExternalLogger } = proxyquire('../src', {
-      '../../log': {
-        error: errorLog
-      }
-    })
-
-    externalLogger = new ExternalLogger({
-      ddsource: 'logging_from_space',
-      hostname: 'mac_desktop',
-      apiKey: 'API_KEY_PLACEHOLDER',
-      interval: 10000,
-      timeout: 5000,
-      limit: 10
-    })
-  })
-
-  afterEach(() => {
-    interceptor.done()
-    errorLog.restore()
-  })
-
-  it('should properly encode the log message', (done) => {
-    let request
-    const currentTime = Date.now()
-
-    interceptor = nock('https://http-intake.logs.datadoghq.com:443')
-      .post('/api/v2/logs')
-      .reply((_uri, req, cb) => {
-        request = req
-        cb(null, [202, '{}', { 'Content-Type': 'application/json' }])
-      })
-
-    const span = {
-      service: 'openAi',
-      trace_id: '000001000',
-      span_id: '9999991999'
-    }
-    const tags = {
-      env: 'external_logger',
-      version: '1.2.3',
-      service: 'external'
-    }
-    externalLogger.log({
-      message: 'oh no, something is up',
-      custom: 'field',
-      attribute: 'funky',
-      service: 'outer_space',
-      level: 'info'
-    }, span, tags)
-
-    externalLogger.flush((err) => {
-      try {
-        expect(request[0]).to.have.property('message', 'oh no, something is up')
-        expect(request[0]).to.have.property('custom', 'field')
-        expect(request[0]).to.have.property('attribute', 'funky')
-        expect(request[0]).to.have.property('service', 'outer_space')
-        expect(request[0]).to.have.property('level', 'info')
-        expect(request[0]).to.have.property('dd.trace_id', '000001000')
-        expect(request[0]).to.have.property('dd.span_id', '9999991999')
-        expect(request[0].timestamp).to.be.greaterThanOrEqual(currentTime)
-        expect(request[0]).to.have.property('ddsource', 'logging_from_space')
-        expect(request[0]).to.have.property('ddtags', 'env:external_logger,version:1.2.3,service:external')
-      } catch (e) {
-        done(e)
-        return
-      }
-
-      done(err)
-    })
-  })
-
-  it('should empty the log queue when calling flush', (done) => {
-    interceptor = nock('https://http-intake.logs.datadoghq.com:443')
-      .post('/api/v2/logs')
-      .reply(202, {})
-
-    externalLogger.enqueue({})
-    expect(externalLogger.queue.length).to.equal(1)
-
-    externalLogger.flush((err) => {
-      expect(externalLogger.queue.length).to.equal(0)
-      done(err)
-    })
-  })
-
-  it('tracer logger should handle error response codes from Logs API', (done) => {
-    interceptor = nock('https://http-intake.logs.datadoghq.com:443')
-      .post('/api/v2/logs')
-      .reply(400, {})
-
-    externalLogger.enqueue({})
-    externalLogger.flush((err) => {
-      expect(err).to.be.an.instanceOf(Error)
-      expect(errorLog.getCall(0).args[0]).to.be.equal(
-        'failed to send 1 logs, received response code 400'
-      )
-      done()
-    })
-  })
-
-  it('tracer logger should handle simulated network error', (done) => {
-    interceptor = nock('https://http-intake.logs.datadoghq.com:443')
-      .post('/api/v2/logs')
-      .replyWithError('missing API key')
-
-    externalLogger.enqueue({})
-    externalLogger.flush((err) => {
-      expect(err).to.be.an.instanceOf(Error)
-      expect(errorLog.getCall(0).args[0]).to.be.equal(
-        'failed to send 1 log(s), with error missing API key'
-      )
-      done()
-    })
-  })
-
-  it('causes a flush when exceeding log queue limit', (done) => {
-    const flusher = sinon.stub(externalLogger, 'flush')
-
-    for (let i = 0; i < 10; i++) {
-      externalLogger.enqueue({})
-    }
-    expect(flusher).to.not.have.been.called
-
-    externalLogger.enqueue({})
-    expect(flusher).to.have.been.called
-
-    flusher.restore()
-    done()
-  })
-})

package/scripts/check-proposal-labels.js

@@ -1,71 +0,0 @@
-/* eslint-disable no-console */
-
-const childProcess = require('child_process')
-const ORIGIN = 'origin/'
-
-let releaseBranch = process.env['GITHUB_BASE_REF'] // 'origin/v3.x'
-let releaseVersion = releaseBranch
-if (releaseBranch.startsWith(ORIGIN)) {
-  releaseVersion = releaseBranch.substring(ORIGIN.length)
-} else {
-  releaseBranch = ORIGIN + releaseBranch
-}
-let currentBranch = process.env['GITHUB_HEAD_REF'] // 'ugaitz/workflow-to-verify-dont-land-on-v3.x'
-if (!currentBranch.startsWith(ORIGIN)) {
-  currentBranch = ORIGIN + currentBranch
-}
-
-const getHashesCommandWithExclusions = 'branch-diff --user DataDog --repo dd-trace-js --exclude-label=semver-major' +
-  ` --exclude-label=dont-land-on-${releaseVersion} ${releaseBranch} ${currentBranch}`
-const getHashesCommandWithoutExclusions =
-  `branch-diff --user DataDog --repo dd-trace-js ${releaseBranch} ${currentBranch}`
-
-childProcess.exec(getHashesCommandWithExclusions, { timeout: 30000 },
-  (withExclusionError, withExclusionStdout, withExclusionStderr) => {
-    if (withExclusionError) {
-      console.error(`stdout:
-${withExclusionStdout}
-stderr:
-${withExclusionStderr}
-`, withExclusionError)
-      process.exit(1)
-      return
-    }
-    if (withExclusionStderr) {
-      console.error(withExclusionStderr)
-      process.exit(1)
-      return
-    }
-    const commitsHashesWithExclusions = withExclusionStdout.split('\n')
-
-    childProcess.exec(getHashesCommandWithoutExclusions,
-      (withoutExclusionError, withoutExclusionStdout, withoutExclusionStderr) => {
-        if (withoutExclusionError) {
-          console.error(`stdout:
-${withoutExclusionStdout}
-stderr:
-${withoutExclusionStderr}
-`, withoutExclusionError)
-          process.exit(1)
-          return
-        }
-        if (withoutExclusionStderr) {
-          console.error(withoutExclusionStderr)
-          process.exit(1)
-          return
-        }
-        const commitsHashesWithoutExclusions = withoutExclusionStdout.split('\n')
-        if (commitsHashesWithExclusions.length !== commitsHashesWithoutExclusions.length) {
-          const commitsWithInvalidLabels = []
-          commitsHashesWithoutExclusions.filter(c1 => {
-            if (!commitsHashesWithExclusions.some(c2 => c2 === c1)) {
-              commitsWithInvalidLabels.push(c1)
-            }
-          })
-          console.error('Some excluded label added in the release proposal', commitsWithInvalidLabels)
-          process.exit(1)
-        } else {
-          console.log('Commit PRs label looks OK')
-        }
-      })
-  })

package/scripts/check_licenses.js

@@ -1,69 +0,0 @@
-'use strict'
-
-const fs = require('fs')
-const path = require('path')
-const readline = require('readline')
-const pkg = require(path.join(__dirname, '..', '/package.json'))
-
-const filePath = path.join(__dirname, '..', '/LICENSE-3rdparty.csv')
-const deps = new Set(Object.keys(pkg.dependencies || {}))
-const devDeps = new Set(Object.keys(pkg.devDependencies || {}))
-
-let index = 0
-
-const licenses = {
-  require: new Set(),
-  dev: new Set(),
-  file: new Set()
-}
-
-const lineReader = readline.createInterface({
-  input: fs.createReadStream(filePath)
-})
-
-lineReader.on('line', line => {
-  if (index !== 0) {
-    const columns = line.split(',')
-    const type = columns[0]
-    const license = columns[1]
-
-    licenses[type].add(license)
-  }
-
-  index++
-})
-
-lineReader.on('close', () => {
-  if (!checkLicenses(deps, 'require') || !checkLicenses(devDeps, 'dev')) {
-    process.exit(1)
-  }
-})
-
-function checkLicenses (typeDeps, type) {
-  /* eslint-disable no-console */
-
-  const missing = []
-  const extraneous = []
-
-  for (const dep of typeDeps) {
-    if (!licenses[type].has(dep)) {
-      missing.push(dep)
-    }
-  }
-
-  for (const dep of licenses[type]) {
-    if (!typeDeps.has(dep)) {
-      extraneous.push(dep)
-    }
-  }
-
-  if (missing.length) {
-    console.log(`Missing 3rd-party license for ${missing.join(', ')}.`)
-  }
-
-  if (extraneous.length) {
-    console.log(`Extraneous 3rd-party license for ${extraneous.join(', ')}.`)
-  }
-
-  return missing.length === 0 && extraneous.length === 0
-}