andrewbranch / definitely-not-slow

This repo has moved:

Andrewbranch

This README outlines the details of collaborating on this Ember application. A short introduction of this app could easily go here.

Prerequisites

You will need the following things properly installed on your computer.

• Git
• Node.js (with NPM)
• Bower
• Ember CLI
• PhantomJS

Installation

• git clone <repository-url> this repository
• change into the new directory
• npm install
• bower install

Running / Development

• ember server
• Visit your app at http://localhost:4200.

Code Generators

Make use of the many generators for code, try ember help generate for more details

Running Tests

• ember test
• ember test --server

Building

• ember build (development)
• ember build --environment production (production)

Deploying

Specify what it takes to deploy your app.

Further Reading / Useful Links

• ember.js
• ember-cli
• Development Browser Extensions
  • ember inspector for chrome
  • ember inspector for firefox

definitely-not-slow's Issues

Dependabot couldn't authenticate with npm.pkg.github.com/andrewbranch

Dependabot couldn't authenticate with npm.pkg.github.com/andrewbranch.

You can provide authentication details in your Dependabot dashboard by clicking into the account menu (in the top right) and selecting 'Config variables'.

Usage outside of DefinitelyTyped

First of all, congrats for this impressive tool.

I'd like to know whether it can be used outside of DefinitelyTyped ecosystem.

To be specific, I'd like to use it to obtain the metrics generated for DefinitelyTyped PR, but for a local types package instead.

For PRs, run against master when type's external dependency is updated

Some types rely on non-DefinitelyTyped types. For instance @types/ramda depends on ts-toolbelt. Updates to these external dependencies (especially utility-types packages like ts-toolbelt) could cause large changes to the benchmarks for a DefinitelyTyped type that are unrelated to the changes made for the PR.

I propose modifying the 2nd item in the "Usage" list, to specify that "aren’t up-to-date" includes packages whose last benchmark used an older version of their dependencies.

This would require a few updates:

1. Storing the version of each dependency used when persisting a benchmark
2. Retrieving the version of each dependency for the prior benchmark
3. In compareBenchmarks, we'd want to check the if the current versions of each dependency (that still matches the semver) is not the same as the stored versions. If a version has changed, then we'd want to run a new benchmark for the package against origin/master and compare against that benchmark.

   • This could get complicated. There would be times when a package's external dependencies have been updated because the dependency's semver version was updated in package.json. For instance, to enforce an older version when the current version is broken, or to update to a new major version. In those cases we may or may not want to run the prior benchmark.

     This part is probably worth a bit of discussion below.