Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shadowed name - geofirestore 3.1.0 #83

Closed
Synercio opened this issue Feb 7, 2019 · 3 comments
Closed

Shadowed name - geofirestore 3.1.0 #83

Synercio opened this issue Feb 7, 2019 · 3 comments
Assignees
Labels
bug Something isn't working

Comments

@Synercio
Copy link

Synercio commented Feb 7, 2019

Hello Team,

I have a little problem when I compile my code to deploy to firebase :

GeoFirestoreTypes.ts[39, 17]: Shadowed name: 'DocumentChange' GeoFirestoreTypes.ts[48, 17]: Shadowed name: 'QueryDocumentSnapshot' GeoFirestoreTypes.ts[53, 17]: Shadowed name: 'DocumentChange' GeoFirestoreTypes.ts[61, 17]: Shadowed name: 'QueryDocumentSnapshot'

my package.json :

{ "engines": { "node": "8" }, "name": "functions", "scripts": { "lint": "tslint --project tsconfig.json", "build": "tsc", "serve": "npm run build && firebase serve --only functions", "shell": "npm run build && firebase functions:shell", "start": "npm run shell", "deploy": "firebase deploy --only functions", "logs": "firebase functions:log" }, "main": "lib/index.js", "dependencies": { "@firebase/firestore-types": "0.x.x", "firebase": "^5.8.2", "firebase-admin": "~6.0.0", "firebase-functions": "^2.1.0", "geofirestore": "^3.1.0", "geokit": "^0.1.3", "moment": "^2.23.0", "request": "^2.88.0", "request-promise": "^4.2.2" }, "devDependencies": { "@types/request-promise": "^4.1.42", "tslint": "~5.8.0", "typescript": "~3.0.3" }, "private": true }

Can you help me ?

Thanks :)

@MichaelSolati
Copy link
Owner

Well this is a simple issue to fix and I'll fix in the version 3.2.0 (coming very soon, next few days). Until then you can probably disable the no-shadowed-name rule in your tslint.json

@MichaelSolati MichaelSolati self-assigned this Feb 7, 2019
@MichaelSolati MichaelSolati added the bug Something isn't working label Feb 7, 2019
@MichaelSolati
Copy link
Owner

Actually that may not be the fix... Can I get your tslint.json?

@Synercio
Copy link
Author

Synercio commented Feb 8, 2019

Hello Michael,

Thanks for your answer.

Here is my tslint.json :

`{
"rules": {
// -- Strict errors --
// These lint rules are likely always a good idea.

// Force function overloads to be declared together. This ensures readers understand APIs.
"adjacent-overload-signatures": true,

// Do not allow the subtle/obscure comma operator.
"ban-comma-operator": true,

// Do not allow internal modules or namespaces . These are deprecated in favor of ES6 modules.
"no-namespace": true,

// Do not allow parameters to be reassigned. To avoid bugs, developers should instead assign new values to new vars.
"no-parameter-reassignment": true,

// Force the use of ES6-style imports instead of /// <reference path=> imports.
"no-reference": true,

// Do not allow type assertions that do nothing. This is a big warning that the developer may not understand the
// code currently being edited (they may be incorrectly handling a different type case that does not exist).
"no-unnecessary-type-assertion": true,

// Disallow nonsensical label usage.
"label-position": true,

// Disallows the (often typo) syntax if (var1 = var2). Replace with if (var2) { var1 = var2 }.
"no-conditional-assignment": true,

// Disallows constructors for primitive types (e.g. new Number('123'), though Number('123') is still allowed).
"no-construct": true,

// Do not allow super() to be called twice in a constructor.
"no-duplicate-super": true,

// Do not allow the same case to appear more than once in a switch block.
"no-duplicate-switch-case": true,

// Do not allow a variable to be declared more than once in the same block. Consider function parameters in this
// rule.
"no-duplicate-variable": [true, "check-parameters"],

// Disallows a variable definition in an inner scope from shadowing a variable in an outer scope. Developers should
// instead use a separate variable name.
"no-shadowed-variable": true,

// Empty blocks are almost never needed. Allow the one general exception: empty catch blocks.
"no-empty": [true, "allow-empty-catch"],

// Functions must either be handled directly (e.g. with a catch() handler) or returned to another function.
// This is a major source of errors in Cloud Functions and the team strongly recommends leaving this rule on.
"no-floating-promises": true,

// Do not allow any imports for modules that are not in package.json. These will almost certainly fail when
// deployed.
"no-implicit-dependencies": true,

// The 'this' keyword can only be used inside of classes.
"no-invalid-this": true,

// Do not allow strings to be thrown because they will not include stack traces. Throw Errors instead.
"no-string-throw": true,

// Disallow control flow statements, such as return, continue, break, and throw in finally blocks.
"no-unsafe-finally": true,

// Do not allow variables to be used before they are declared.
"no-use-before-declare": true,

// Expressions must always return a value. Avoids common errors like const myValue = functionReturningVoid();
"no-void-expression": [true, "ignore-arrow-function-shorthand"],

// Disallow duplicate imports in the same file.
"no-duplicate-imports": true,


// -- Strong Warnings --
// These rules should almost never be needed, but may be included due to legacy code.
// They are left as a warning to avoid frustration with blocked deploys when the developer
// understand the warning and wants to deploy anyway.

// Warn when an empty interface is defined. These are generally not useful.
"no-empty-interface": {"severity": "warning"},

// Warn when an import will have side effects.
"no-import-side-effect": {"severity": "warning"},

// Warn when variables are defined with var. Var has subtle meaning that can lead to bugs. Strongly prefer const for
// most values and let for values that will change.
"no-var-keyword": {"severity": "warning"},

// Prefer === and !== over == and !=. The latter operators support overloads that are often accidental.
"triple-equals": {"severity": "warning"},

// Warn when using deprecated APIs.
"deprecation": {"severity": "warning"},

// -- Light Warnings --
// These rules are intended to help developers use better style. Simpler code has fewer bugs. These would be "info"
// if TSLint supported such a level.

// prefer for( ... of ... ) to an index loop when the index is only used to fetch an object from an array.
// (Even better: check out utils like .map if transforming an array!)
"prefer-for-of": {"severity": "warning"},

// Warns if function overloads could be unified into a single function with optional or rest parameters.
"unified-signatures": {"severity": "warning"},

// Warns if code has an import or variable that is unused.
"no-unused-variable": {"severity": "warning"},

// Prefer const for values that will not change. This better documents code.
"prefer-const": {"severity": "warning"},

// Multi-line object literals and function calls should have a trailing comma. This helps avoid merge conflicts.
"trailing-comma": {"severity": "warning"}

},

"defaultSeverity": "error"
}
`

However, I suppose it came from my configuration because on other computer the problem not appears.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants