Sharing VS Code extensions across teams

Giacomo Cerquone — Thu, 28 Apr 2022 14:11:04 +0000

Let's say you have a big monorepo (not unusual at all in these days) and that you have 20+ developers working on it and you have many tools to improve the quality of the written code.
How do you keep the developer experience at the top?

This is one of the many challenges we face at Musixmatch in our front-end codebase.

We're aware of several generic ways in which companies can provide a cohesive environment to work on. There is Vagrant, but also cloud development solutions with workspaces that provide you with stuff already configured for you.

But what about something more specific to the editor/IDE in use? What if there was a way to inform the developers that a certain project requires certain extensions and settings?

We use Visual Studio Code and we believe it's important for the developers to be on common ground when talking about the software we use to write code, and there is a way.

The .vscode folder

Visual Studio Code has both a user configuration and a workspace one that can be found inside the project, within a ".vscode" folder that contains all the necessary json files to properly configure the editor.

The overall configuration of Visual Studio Code will be a merge of the configuration inside the developer computer and the one inside the project.

Can we do the same but for extensions and not just settings?

The extensions.json file

Just the other day I was investigating why we were encountering many difficulties in writing stories with Storybook for our React Native internal design system (called Ritmo).

We're used to writing our stories in MDX because we found it to be more declarative than javascript. Sadly, though, there is no straightforward support from linters and syntax highlighters over MDX files*.

Thanks to the following VS Code extension and the related eslint plugin, we enabled linting and syntax highlighting also inside MDX files.

So, Visual Studio Code has a way to request users working on a project, that contains a .vscode/extensions.json file, to install certain extensions. Here is an example:

MDX stands for "Markdown JSX", it's an extension of the more classical MD format that allows writing JSX (e.g. using React components) inside markdown files.

I find this to be a little useful gem, also I'd love to see this approach used within open source projects.

What do you use instead to keep your projects synced and well organized between your devs?

Re-thinking React Native env vars

Giacomo Cerquone — Sun, 29 Dec 2019 10:31:53 +0000

You can read this post on my personal blog too.

Please let me know of your ideas, solutions and thoughts about all this

We can say it: some parts of React Native are still missing and sometimes this may keep us on alert when developing an app made for the public.
One of the main pieces I think it's missing, is the use of environment variables.
This post comes from problems and difficulties I experienced while building and working on pretty complex React Native apps.
For sure many packages tries to help, yet I didn't find one that was satisfying my requirements.
So if you're searching for a straightforward solution, leave hope. Instead, if you know about this problem and didn't find a solution that fits your need, keep reading :)

Requirements

Let's go for steps:

I need many builds of my app and each of them must be configured in a specific way.
The same way of applying the configuration is needed while developing (so to have a "dev" configuration).
It's obvious that needing a build time configuration (a configuration that gets applied in a specific build), the configuration must come from outside the javascript code. And this is because we always build using native tools (gradle/xcodebuild).
The configuration can also be guided by a single value. For example, I could inject a 'stage' string, and let the javascript code picks up a particular configuration object with the correct values.

In fact, what we want isn't the configuration of an environment, but the configuration of a specific build in a specific way. Let's understand why in the next paragraph.

NOTE: As you may have read from this other post, I'm recently excluding Expo from the complex apps I'm working on.
On Expo, we have what it's called "OTA channels". When we request a particular build, you are asked for a string that represents the channel of the app. It will listen to this channel and will retrieve the OTA updates. With that I could accomplish what I'm asking.

Why not a standard solution?

First of all, why do we use env vars at all?
To store secrets and to configure behaviours of an application.
But everything in a front-end app is free to be seen by anyone, so in React Native, for example, we might use them only to configure behaviors in a standard way.
Then we must distinguish between:

Using env vars in a boxed solution to create apps (one like create-react-app, react native, angular-cli, etc.)
Using them in a custom solution (one that reimplements a webpack config basically).

In the first kind, you'll always be restricted somehow from the fact that those tools were born exactly to avoid the configuration pain.
In the second one, you're free to go but it's very hard to reimplement it and you will need to fix so many weird stuff during the journey that it may not worth the risk.

So to find a solution in React Native, we can spy on solutions implemented by other tools.
Create react app, for example, gives you this: https://create-react-app.dev/docs/adding-custom-environment-variables/ and it's done through a custom webpack configuration done by the facebook team here that uses this code to collect all the env vars defined with a REACT_ prefix for each of them.

Nice, but since in React Native we're left alone, we should reimplement a custom webpack conf.
Luckily there is already a webpack plugin to inject env vars, but, as we anticipated earlier, a custom configuration is really hard to achieve.
This is the only attempt at doing it that I could find online but it's not updated and it's so awkward that I'd prefer to not embark myself into a thing like this. (plus I'm almost sure that it doesn't work as it is).

Let's find a different way to solve this issue then.

The idea

This is the idea: why use env vars when we already can export something directly through the same language we're writing the code?
Of course, this doesn't come out of nowhere. Many tools do this already (metro.config, .babelrc, etc.) but we're not used to do it in our application's code.
Examining the twelve-factor app manifesto we can get an intuition of why is that and what are the consequences of doing this:

Another approach to config is the use of config files that are not checked into revision control, such as config/database.yml in Rails.

Then it basically says that this is prone to human errors (like everything I'd say) and then there are these assumptions:

Env vars are easy to change between deploys without changing any code.
Unlike config files, there is little chance of them being checked into the code repo accidentally.
They are a language and OS-agnostic standard.

In React Native:

The first sentence is true but only if the code runs in a machine we control.
The second is pretty much false. We're used to have dotenv files, so there is the same risk of committing that instead of a config file.Plus in front-end apps, as we said, env vars are just configuration values.
The third sentence implies that should be easy to read them from the code. It should be indeed, but in the current situation it's absolutely the opposite.

Why do we have such inconsistencies with this manifesto? Simple, because environment variables were started to be used in the developing world when you needed to configure an environment, indeed, where your code would have run, but not all kinds of development allow this.

The solution

I won't go into details with all the implementations I tried and discarded, this post would become huge with all the considerations, the pros and cons. Consider only that, luckily for you, I'm using the following solution in many production apps and it's going ok.
It's very basic:

Define an active.env.js file at the root of the project like this:

export default "dev"

Define configuration values in an env.js file like this:

import { Platform } from "react-native"

import active from "./active.env"

const envs = {
  stage: {
    DEV_API: "http://staging.api.com",
    SOUNDS: Platform.OS === "android" || false,
  },
  prod: {
    DEV_API: "http://prod.api.com",
    SOUNDS: Platform.OS === "android" || false,
  },
  dev: {
    DEV_API: "http://dev.api.com",
    SOUNDS: Platform.OS === "android" || false,
  },
}

export default envs[active]

You'll use a shell script (or an npm package) within an npm script called, for example, "set-stage" which will write inside the active.env.js file the right string (env) to apply to the project. Something like this:

"set-stage": "shx echo \"export default 'stage';\"> active.env.js",

From wherever you want, import a configuration value like this:

import { DEV_API } from "env.js"

Now within each build process, you just have to automatize the changing of the content of the active.env.js file and you and leave it as "dev" the rest of the time.
This can be done through command concatenation (&& inside the npm scripts).

OTA channels

Another problem we solve in such easy way is the creation and definition of release channels (from expo terminology) with your favorite OTA updates system.
With Microsoft CodePush, which I talked about here for example, you can import the CODE PUSH key from the right env javascript file at build time and correctly direct the updates.

Alternatives

react-native-dotenv

This package goes very close to accomplish what I want for my build workflow but sadly they reached a dead-end for various reasons:

No possibility to choose a certain env file. Someone tried to implement it through an env var (a sort of parent env var to orchestrate everything) but hit a wall when working with gradle and xcode
The package is not maintained anymore and there is some low-level problem to the whole architecture that forces you to edit the files that import the env vars when you change them to let them retrieve the new values. (I assume because of babel)

react-native-config

This one is the best you can get without coming up with your own implementation.
The problem is that to achieve all those functionalities, it's built as a dependency and not as a dev dependency (it must be linked and so the code runs at runtime too) and you have to tinker a bit on how to configure it properly both on xCode and Android Studio.

DEV Community: Giacomo Cerquone