[ENHANCEMENT] Enable refactoring dangerfile.ts into modules

Describe your issue We have pretty large dangerfile.ts with a lot of functions and rules, which could easily be refactored into, say, few functions, and the natural way is to put each function into its own module, for example in the danger folder.

For the sake of example let’s say that our dangerfile.ts looks like this:

import {results, fail, message}  from 'danger';

function checkPR(...){
   const isBad = ...
   if(isBad){
      fail(...)
   }
}

function checkAllResults(){
   const {fails} = results;
   if(fails.length == 0){
      message("Great job!");
   }
}

checkPR();
checkAllResults();

And we want checkPR function to be inside its separate file danger/checkPR.ts, so our dangerfile would look like this:

import {results, message}  from 'danger';
import checkPR from './danger/checkPR';

function checkAllResults(){
   const {fails} = results;
   if(fails.length == 0){
      message("Great job!");
   }
}

checkPR();
checkAllResults();

Because we use Typescript, we would like the file danger/checkPR.ts to contain its own import {fail} from 'danger'. The problem is, it seems like the abovementioned construction would work only if danger/checkPR.ts contains NO import from danger at all. At the same time, I noticed that the import in dangerfile.ts gets removed automatically, and it just works fine both at the compile-time and run-time.

Suggestion/Question

I think it would be really nice to enable such refactoring, and if I’m not mistaking and the danger runtime is responsible for removing that import declaration at the top of dangerfile.ts, why not extend that rule to, say, all files in the danger folder (in root)? Another option I see is adding some annotation which would serve the same purpose

[fbartho]

Personally, I include a file like this, and then all extra sourcefiles import from there instead of the danger module:

export {};
// DangerJS has a weird compile/runtime environment, but this is a stable detail!
// Briefly documented here:
// https://github.com/danger/danger-js/blob/master/docs/usage/extending-danger.html.md#writing-your-plugin

import { DangerDSLType } from "../../../node_modules/danger/distribution/dsl/DangerDSL";

// Provides dev-time type structures for  `danger` - doesn't affect runtime.
declare global {
  let danger: DangerDSLType;
  function warn(message: string, file?: string, line?: number): void;
  function fail(message: string, file?: string, line?: number): void;
  function markdown(message: string, file?: string, line?: number): void;
}

[orta]

I don’t think so. Danger owns the runtime, importing danger will always raise an exception if it gets through correctly. I also don’t want the config and documentation weight from a describing and controlling that subset