The UpgradeJS Blog

As the upgrade team, one of our most significant challenges is the initial setup of each project, as many of the tools we utilize for inspection need distinct and customized configurations. This is due to the countless methods in which JavaScript/TypeScript projects can be constructed.

In today’s demonstration, we will introduce you to our new open source project called plugin-preloader and show you how you can use it to simplify your workflow if you encounter similar issues as we do.

In a previous post, I covered some useful static code analysis tools for getting a sense of the size of a Node.js application, as well as the health of its external dependencies. This post will continue to look at static analysis tools, with a focus on understanding and visualizing the application’s architecture, patterns (good and bad), and internal dependencies.

In this blog post, I initially intended to discuss upgrading React Native applications using the “backwards-compatible” approach. However, I discovered an opportunity to explore another interesting topic: An upgrade regenerating the project.

Join me as we dive into a case study where I successfully upgrade a React Native iOS-targeted application from version 0.59 all the way to the latest version, 0.71!

At OmbuLabs and UpgradeJS we love using React to create dynamic and scalable user interfaces on the front-end of web, mobile, and desktop applications.

With the release of React v18.0, several new features and enhancements have been added that can improve the development experience and boost the performance of React applications.

In this post, we will provide a guide to upgrading your React application from version 16.x to version 18.x, so that you can take advantage of the latest features and improvements.

My team and I were upgrading an OSS project for research purposes, and this blog was written after the actual upgrade was done. Here we will highlight why the step of inspecting the application with SonarQube-like tool is essential and what we missed because we should have checked it during the upgrade project.

When we test our applications, it’s often useful to use more than one tool or framework for different kinds of tests.

For example, in a Backend-for-Frontend (BFF) application, we may have end-to-end (e2e) tests and unit tests. We might use a tool like Cypress for e2e testing and Jest for unit testing.

Each of these tools can produce a test coverage report, but wouldn’t it be nice to be able to combine all our test coverage data into one report? With IstanbulJS, we can!

In this article, I’ll show you how.

Whether you’re joining a team to work on an existing application, or just want to get a better idea of the status of the application you’ve been working on for a while, static analysis tools can help.

These tools can provide you with a better sense of the size and scope of your application, its architecture, and provide insight into areas of importance, high complexity, low test coverage or poor testability, and more.

Of course, these tools are no substitute for human review and team discussion, but they certainly can be used to expedite that process.

In the fast-paced world of software development, keeping track of dependencies and ensuring they are compatible with the latest version of Node can be a daunting task. This is where depngn comes in - a powerful CLI tool designed to help developers determine if their dependencies support a specific version of Node.

When we join a project and it’s full of jQuery code everywhere that mostly handles simple functions like: selecting elements, add style to an element, handle AJAX request, and it was added a long time ago, maybe it’s time to start migrating small things to simple JavaScript code.

React 18 has been out for about 8 months now and it contains a ton of goodies for both end-users and library authors. However, there is one new change that seems to keep coming up in GitHub issues and forum posts – useEffect now fires twice under Strict Mode in development. In this post, I’ll briefly go over exactly what Strict Mode in React is and then offer some advice on dealing with the change – as well as a few useEffect best practices.

The JavaScript ecosystem is moving incredibly fast these days. It seems like there’s a new framework or library every other day. For developers trying to jump in, it can be daunting to figure out what tools to choose for your project. It can also be difficult to tell whether or not the newest thing is ready for production.

So, to help you navigate the maze of choices, I’ve compiled a list of the basic things you need to get started with a modern JavaScript project. This collection isn’t exhaustive, but represents tech that is both current and stable (not ancient, but not so new that it’ll break prod). Also, when applicable, I’ll include upcoming tech that is promising, but maybe not quite ready for primetime.

No, not that Meta

What most developers call JavaScript frameworks (React, Vue, Svelte, etc) can more accurately be thought of as UI Libraries. While they can make writing the front end of websites and apps simpler, they have no opinions at all regarding what goes on further back in the stack. They don’t even have prescribed methods of organizing the folders and files in your projects.

Full-fledged frameworks (think Rails or Django), on the other hand, will usually be very opinionated and expect the code to be organized in a certain way, with the hope that this will lead to shorter development time by getting rid of analysis paralysis and bikeshedding.

Thankfully, there are libraries available to fill that role in the JavaScript ecosystem. Since most UI libraries are called “frameworks”, these more full-featured libraries have taken to calling themselves “meta-frameworks”.

In a nutshell, they let JavaScript developers focus on the “what” and take care of most of the “how” for you.

We, full stack Rails engineers, have come a long way. We started off as full stack engineers with our backend and frontend all in one framework. We had the asset pipeline (with sprockets) to help us maintain this ecosystem. When the time came we introduced webpacker to fill in where sprockets fell short.

In this post we will take a look at how we can take the next step on our journey by migrating from webpacker to esbuild.

When we run tests, we don’t want to hit external services in most cases, so our tests don’t depend on external services and are more stable. We can use gems like VCR or WebMock to stub the requests that are done by the Rails application, but when the request is initiated by the JavaScript code… that’s a different story.

“You can have a little imperative React, as a treat.”

When building modern applications with React, Function Components and Hooks are the de facto way to do it. Hooks make your code more declarative and easier to reason about (usually).

However, with all great hammers, you run the risk of everything looking like a nail. Occasionally, some more object-oriented solutions might be the right tool for the job. For example, what if you had a child component that contained a function that needed to be called from the parent? You might want an instance method, but we don’t use Classes anymore!

Fear not – you don’t have to abandon Hooks to be able to call methods on child components. In this post, I’ll show you how – using forwardRef and useImperativeHandle.