consider turning on noImplicitAny by default

[IgorMinar]

currently our blueprints don't pass the noImplicitAny check - we should fix that.

• understand the impact
• change the config
• update blueprints that fail the check

Current failures for an empty project:

[DiffingTSCompiler]: Typescript found the following errors:
  app/sample-45.spec.ts (7, 71): Parameter 'app' implicitly has an 'any' type.
  app/sample-45.spec.ts (12, 65): Parameter 'app' implicitly has an 'any' type.
  app/sample-45.ts (14, 17): Parameter 'meaning' implicitly has an 'any' type.

@rkirov @alexeagle - what's your guidance on this?

[alexeagle]

Why is it necessary to "pass the noImplicitAny check" - what is requiring that?

My (our?) guidance is: for someone brand-new to TypeScript, optional typing is a feature and helps them ramp up. Similarly, when migrating an existing codebase (eg what we did for Angular), noImplicitAny is a critical step to make this tractable and incremental.
However, anyone with some experience who is starting a new app that's not just a toy example or rapid prototype is better off with noImplicitAny turned on from the beginning.

[Brocco]

I agree that turning on noImplicitAny in the tsconfig file would not be a good idea as it could be cumbersome for someone starting with TypeScript.

That being said, I think that the initial output of the blueprints should be accommodating if the user wants to turn that setting on, they should not have to modify any of the code which is generated via our blueprints.

[IgorMinar]

sgtm - let's update the blueprints but keep the flag off by default.

On Tue, Dec 15, 2015 at 7:34 AM Mike Brocchi notifications@github.com
wrote:

I agree that turning on noImplicitAny in the tsconfig file would not be a
good idea as it could be cumbersome for someone starting with TypeScript.

That being said, I think that the initial output of the blueprints should
be accommodating if the user wants to turn that setting on, they should not
have to modify any of the code which is generated via our blueprints.

—
Reply to this email directly or view it on GitHub
#107 (comment)
.

[alexeagle]

Make sure you have some testing with noImplicitAny=true so the invariant
you desire is enforced by the continuous build! :)

On Tue, Dec 15, 2015 at 8:05 AM Igor Minar notifications@github.com wrote:

sgtm - let's update the blueprints but keep the flag off by default.

On Tue, Dec 15, 2015 at 7:34 AM Mike Brocchi notifications@github.com
wrote:

I agree that turning on noImplicitAny in the tsconfig file would not be a
good idea as it could be cumbersome for someone starting with TypeScript.

That being said, I think that the initial output of the blueprints should
be accommodating if the user wants to turn that setting on, they should
not
have to modify any of the code which is generated via our blueprints.

—
Reply to this email directly or view it on GitHub
<
https://github.com/angular/angular-cli/issues/107#issuecomment-164799941>
.

—
Reply to this email directly or view it on GitHub
#107 (comment)
.

[Brocco]

The PR I submitted (#213) covers all aspects specified here by @IgorMinar.

• The noImplicitAny flag is turned off in the blueprints so as to not force developers to have that flag on by default.
• All templates have been updated so they compile without issue if the flag is turned on
• A test was added to verify compilation if the noImplicitAny flag is turned on, which will capture any errors introduced with blueprint upgrades

[IgorMinar]

Nice! Thanks
On Wed, Feb 17, 2016 at 5:03 AM Mike Brocchi notifications@github.com
wrote:

The PR I submitted (#213 #213)
covers all aspects specified here by @IgorMinar
https://github.com/IgorMinar.

• The noImplicitAny flag is turned off in the blueprints so as to not
  force developers to have that flag on by default.
• All templates have been updated so they compile without issue if the
  flag is turned on
• A test was added to verify compilation if the noImplicitAny flag is
  turned on, which will capture any errors introduced with blueprint upgrades

—
Reply to this email directly or view it on GitHub
#107 (comment)
.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}