TypeScript TS7016 Could not Find Declaration Implicitly has any type

When building TypeScript modules, we may come across the TS7016 error. This error indicates that the modules being imported has no strongly typed definitions, and we are trying to use them in a project where type declaration is required. This is a more detail description of what this error may look like.

error TS7016: Could not find a declaration file for module './ozkary/ozkary.package'. '/ repos/aiengine/src/modules/speech/speech.package.js' implicitly has an 'any' type.

To clarify this error, this just really means that we are attempting to use a JavaScript (not well define types) file on a TypeScript (strongly-typed) project which essentially defeats the purpose. Do not panic yet, there are ways to solve this dilemma. Let us review our options.

Allow for Implicit Any Imports (tsconfig.json)

On a TypeScript project, there is a tsconfig.json file which provides all the information on how to compile the project.  The CompilerOptions node contains several configuration entries. By default, the NoImplicitAny settings is set to false, and it may not be visible on your settings.  This setting allows our project to use files and libraries that are purely written with JavaScript.  To override this error, we can add the value and set it to true as shown below:

"compilerOptions": {     "module": "commonjs",     "noImplicitReturns": true,     "noUnusedLocals": false,     "outDir": "lib",     "sourceMap": true,     "strict": true,     "target": "es2017",        "noImplicitAny": true

Use JavaScript Libraries with TS Support

If we are using TypeScript for a project, it is probably because we want to use a strongly-typed language. When this is the case, we need to use libraries that support TypeScript. If a package we are using is causing this error, we need to look at the latest package updates and see if the latest version do have TypeScript support.  If this is not the case, then overriding the behavior on the tscofig.json file is the fallback option.

Ensure the File Extension is TS not JS

This may seem obvious, but this is a common mistake. When adding new files to the TypeScript project, we need to make sure the file extension is TS not JS. This tiny mistake for sure raises the TS7016 error. It is sometime important to observe and take a close look at the file extension when we see this error.

Strongly Typed Classes instead of Function Components

Using TS files extensions is not enough to indicate that our classes are strongly type. We also need to refactor our code to follow the TypeScript standards. This means replacing JavaScript function component declarations with interfaces and classes that declare strongly type data members.

I hope this was helpful and that it can help in resolving this error from your project. Feel free to add more suggestions on resolving this error on the comments sections.

Thanks for reading.

Originally published by ozkary.com

When building TypeScript modules, we may come across the TS7016 error. This error indicates that the modules being imported has no strongly...

Read Article →

Feature Branching and Pull-Request Strategy with Git, GitHub and VSCode

When a software development team grows, and we have multiple people working in parallel. Or  even if the team is small, but there are multiple feature changes, the source control versions can quickly become unmanageable with code conflicts. A way to solve this problem is to have developers work on different areas/features of the app.  Even though this helps somewhat, there are still potential problems that can be prevented by following a feature branch and pull-request strategy. This strategy helps us prevent typical problems during the software development cycles. To better understand, let us see what this strategy is about.

Code Repository Branches

As part of the Software Development Lifecycle (SDLC), it is a must practice to use source control software which enables us to track the changes on the software. To isolate the code changes between a development and production version, the concept of branches is used. A branch enables us to track code changes during the development phase and later merge them once that code is deployed to production.

This approach provides the flexibility to create patches from production branch while the development branch is still undergoing changes. The same concept is applicable to the development branch when we want to isolate independent feature changes in which some can be completed much sooner than others.

Feature Branches

A feature branch enables us to isolate code changes for each specific feature.  A “feature” can be a change request, enhancement, or defect fix on the application. A feature branch can also be used to create a software patch from a specific version.  These are often referred as a firefight fix.

The idea behind a feature branch is to create changes or building blocks that are isolated and easily tested independently. For this approach to be successful, we must follow a specific process.

Feature Branch Process

When creating feature branches, we need to adhere a process that is easily repeatable.  In the case of feature development, we want to always create a feature branch from the development branch. Once the feature is complete and ready to test, the code is pushed to the remote repo, and a pull-request (PR) is created which enables the team to run code reviews and merge the code back into development.

Once a feature branch has been merged into development, it is important that all other open feature branches continuously merge back with development to minimize the risk of conflicts. This enables a smooth code merge from multiple feature branches back into the source branch.

Feature Branching with Git

Git is a popular source control management tool that operates on a client workspace. This is not to be confused with Server (remote) Repository like GitHub and Team Services (TFS). The purpose of Git is to clone a remote repo locally and make changes that are only reflected on the local workspace.  For the changes to be available to the rest of the team, the changes must be pushed from a local repo to the remote repo.

When using Git and working on Feature branches, we want to follow a serious of steps that enable us to get the latest changes from the development remote branch and then create a feature branch. We can do this by using Git UI client tools. In our case, we want to use GIT CLI from Visual Studio Code. From VS Code, open a terminal window and let us look at the commands we need to get this done.

Note:  First clone a remote repo and ensure there is development branch. These commands can be done from VS Code Terminal.

 

Command	Description
git checkout development	Checkout the dev branch
git pull origin development	Pull most recent from remote repo
git checkout -b f_featureName	Create a feature branch from dev. This is where the changes are done.
git add -A	Stage all the ongoing changes
git commit -a -m "#id my new changes"	Commit locally all the changes, add comments and possible issue #id
git pull origin development	Pull from development to merge any pending changes from the remote repo
git push origin f_featureName	Push to the remote repo

 

These are the basic set of commands that enable us to create another branch from the development branch. We should notice that for our feature branch we can use a naming convention (f_*) that can easily tell us what the branch is for. Once the branch is created, we can make the code changes and push our new branch to the remote repo.

Note: It is important to continuously merge from development before pushing the changes.

GitHub Pull-Request

After we have pushed to the remote repo, we can now open a pull-request. This is a gated process which signals to the team that a code review and merge should be executed. A PR can be requested from a GitHub project website (branches page) or using GitHub CLI which can be found at this location https://github.com/cli/cli The GitHub CLI is a sorely needed feature that can enable us to easily create PRs from VSC ode terminal.

After a pull request is merged back into the development branch, the feature branch can be safely deleted from both the remote (team - build manager) and local repos (developer).

Summary

Software development is a complex process, and we need to constantly be learning and creating new processes that can increase our productivity by reducing possible downstream problems. The feature branch pull-request strategy is a simple, repeatable, and valuable process of helping teams work with multiple versions of the product and rapidly adapt to changes.

Thanks for reading.

Originally published by ozkary.com

When a software development team grows, and we have multiple people working in parallel. Or  even if the team is small, but there are multi...

Read Article →