At some point in the future, we want to re-add the immutable rules back in.
If you work on this issue, run 'git log -p' output to find them.

We want to set "grouped-imports": true for ordered-imports, as follows:

"ordered-imports": [
      true,
      {
        "import-sources-order": "lowercase-last",
        "named-imports-order": "any",
        "grouped-imports": true
      }
    ],

We can't do this yet though as ordered-imports can't tell library from non-library imports.

Needs palantir/tslint#3654

This PR poetapp/node#612 had an unused interface but the lint passed.

Would be nice if the linter caught these.

This conflict doesn't allow work properly the following rules

• indent
• max-line-length

Step by to reproduce and fix it

When I added the task tslint-config-prettier-check in the package and execute it the output was:

Conflict rule(s) detected in ./poet-tslint.json:
indent
max-line-length

For resolving it, we have to remove this lines:

after that we have to add this rules here,

like as result:

"prettier":  [true, {
   "singleQuote": true,
   "semi": false,
   "printWidth": 120,
   "tabWidth": 2
}]

This rule prevents me from using names that start with I for interfaces even if I am not using I as a prefix.

https://github.com/poetapp/tslint-rules/blob/master/poet-tslint.json#L13

      "interface-name": [true, "never-prefix"],

See poetapp/node#215, I want to use the names IPFSObject and IPFSConfiguration for configuration, but I can't because tslint is throwing errors about I prefix's

ERROR: /home/kenny/projects/poet/node/src/Helpers/IPFSClient.ts[5, 11]: interface name must not have an "I" prefix
ERROR: /home/kenny/projects/poet/node/src/Helpers/IPFSClient.ts[18, 11]: interface name must not have an "I" prefix

This:

await this.messaging.publishPoetTimestampsDownloaded(matchingPoetTimestamps)

is being changed into this:

+      await this.messaging.publishPoetTimestampsDownloaded(
+        matchingPoetTimestamps
+      )

by the current rules. I don't think this case makes the code more readable.

But in cases with more parameters it does make the code more readable.

I suspect this is being done by prettier.

EDIT

I noticed this is happening for conditions too:

if (blockchainPoetMessage.version[i] !== this.configuration.poetVersion[i])
  return false

is being changed into

if (
  blockchainPoetMessage.version[i] !== this.configuration.poetVersion[i]
)
  return false

For example in this code

  async updateEntryPairs({ entry, claim, ...rest }: { claim: Claim; entry: Entry }) {
    const logger = this.logger.child({ method: 'publishEntryDownload' })
    logger.trace('started claim update hash pairs')
    this.updateClaimIdIPFSHashPairs([
      {
        claimId: claim.id,
        ipfsHash: entry.ipfsHash,
      },
    ])
    logger.trace('finished claim update hash pairs')
    return {
      claim,
      entry,
      ...rest,
    }
  }

  private async updateClaimIdIPFSHashPairs(claimIdIPFSHashPairs: ReadonlyArray<ClaimIdIPFSHashPair>) {
    const logger = this.logger.child({ method: 'updateClaimIdIPFSHashPairs' })

    logger.trace({ claimIdIPFSHashPairs }, 'Storing { claimId, ipfsHash } pairs in the DB.')

    const results = await Promise.all(
      claimIdIPFSHashPairs.map(({ claimId, ipfsHash }) =>
        this.collection.updateOne({ ipfsHash }, { $set: { claimId } }, { upsert: true })
      )
    )

    const databaseErrors = results.filter(_ => _.result.n !== 1)

    if (databaseErrors.length) logger.error({ databaseErrors }, 'Error storing { claimId, ipfsHash } pairs in the DB.')

    logger.trace({ claimIdIPFSHashPairs }, 'Storing { claimId, ipfsHash } pairs in the DB successfully.')
  }

this.updateClaimIdIPFSHashPairs returns a Promise (since it's declared as an async function). Ignoring the promise returned by updateClaimIdIPFSHashPairs means that any error thrown inside that function will get ignored, too.

This is solved by just adding await, that'll throw if the promise gets rejected, which will eventually get caught higher up in the call stack and logged/retried.

Having a lint rule prevent ignored Promises would allow catching these potential bugs in Travis

Can't think of any case in which we'd want to allow them.

See https://palantir.github.io/tslint/rules/no-any/ and https://palantir.github.io/tslint/rules/no-unsafe-any/ for rationale.

On registry https://registry.npmjs.org, the "latest" version (v5.0.11) of dependency travis-deploy-once has the following deprecation notice:

We recommend to use Travis Build Stages instead

Marking the latest version of an npm package as deprecated results in the entire package being considered deprecated, so contact the package author you think this is a mistake.

Affected package file(s): package.json

If you don't care about this, you can close this issue and not be warned about travis-deploy-once's deprecation again. If you would like to completely disable all future deprecation warnings then add the following to your config:

"suppressNotifications": ["deprecationWarningIssues"]

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper App’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

Member ordering prevents declaring methods ( that are a result of calling a function ) after fields. It seems to not understand that we are returning a function so it treats it as a field and complains.

Example with pipe

import { pipe } from 'ramda'
export class Example {
  private readonly someField: string
  constructor(someField) {
    this.someField = someField
  }
  private readonly foo = (n) => n + 1,
  private readonly bar = (n) => n * 2,
  public readonly baz = pipe(this.foo, this.bar)
}

baz is seen as a field, so it complains that it is declared below methods. tslint:fix tries to put baz up with the other fields before the constructor which will not work.

https://palantir.github.io/tslint/rules/no-magic-numbers/
https://palantir.github.io/tslint/rules/no-console/
https://palantir.github.io/tslint/rules/no-implicit-dependencies/
https://palantir.github.io/tslint/rules/comment-format/
https://palantir.github.io/tslint/rules/promise-function-async/

Some of these were introduced in tslint 5.11.0, so we'll need to bump up the version

It forces some changes I personally don't find more readable.

Examples:

         {
-          $or: [
-            { failureType: null },
-            { failureType: { $exists: false } },
-            { failureType: { $ne: FailureType.Hard } },
-          ],
+          $or: [{ failureType: null }, { failureType: { $exists: false } }, { failureType: { $ne: FailureType.Hard } }],
         },

Or this:

    const handleErrors = async (error: Error) => {
      if (error instanceof NoMoreEntriesException) {
        logger.trace(error.message)
      } else if (error instanceof InvalidClaim) {
         await updateEntryFailureReason(error.ipfsHash, FailureType.Hard, error.failureReason)
      } else if (error instanceof IPFSError) {
         logger.warn(error)
         await updateEntryFailureReason(error.ipfsHash, FailureType.Soft, FailureReason.IPFS)
      }
    }

Changes to:

    const handleErrors = async (error: Error) => {
      if (error instanceof NoMoreEntriesException) logger.trace(error.message)
      else if (error instanceof InvalidClaim)
        await updateEntryFailureReason(error.ipfsHash, FailureType.Hard, error.failureReason)
      else if (error instanceof IPFSError) {
        logger.warn(error)
        await updateEntryFailureReason(error.ipfsHash, FailureType.Soft, FailureReason.IPFS)
      }
    }

We currently are unable to use the following format for no-op functions: const noop = () => {}

The initial discussion was held in here

Opening this issue up for further discussion on allowing empty return blocks.

based on poetapp/poet-js#155

I proposed adding this rule in #54 but now I realize it doesn't play well with absolute paths and devDependencies:

WARNING: /usr/src/app/src/API/API.ts[5, 38]: Module 'Configuration' is not listed as dependency in package.json
WARNING: /usr/src/app/src/API/API.ts[6, 36]: Module 'Helpers' is not listed as dependency in package.json
WARNING: /usr/src/app/src/API/API.ts[7, 27]: Module 'Messaging' is not listed as dependency in package.json
WARNING: /usr/src/app/src/API/FileController.test.ts[1, 26]: Module 'riteway' is not listed as dependency in package.json
WARNING: /usr/src/app/src/API/FileController.ts[7, 35]: Module 'Helpers' is not listed as dependency in package.json
WARNING: /usr/src/app/src/API/FileController.ts[8, 39]: Module 'Helpers' is not listed as dependency in package.json
WARNING: /usr/src/app/src/API/FileController.ts[9, 27]: Module 'Helpers' is not listed as dependency in package.json

There's a ton of these messages in the Travis output.

Underlying issue: palantir/tslint#3483

Manually whitelisting paths is not an option for us.