The following is a deeper dive into the technical nuances of maintaining your team’s workspace within vets-website/src/platform

Workspaces inside src/platform

Similar to code within src/applications, the Release Tools Team is responsible for initial setup of any yarn workspaces inside src/platform code. After the initial set up, Platform teams and approved app-teams can maintain their corresponding workspaces.

Workspaces have been added to the top-level directories in src/platform. Currently, the main difference from the workspaces in src/applications is that the workspaces in src/platform export modules, which are defined in the project's package.json's exports filed. To add exports:

  1. in the package.json of a src/platform workspace, add an "exports" field. Then, for every module/export you want to be made available outside of the workspace, add an alias, e.g.

    "exports": {
      "./someModule": "./path/to/some/module.js"
    }
    CODE

Adding the exports field means that only those modules specified can be exported - this prevents applications from importing modules not meant to be exported.

We make use of aliases, e.g. ./someModule to make importing simpler. This would be used in an application like so:

import module from "@department-of-veterans-affairs/platform-{directory}/someModule"
CODE

2. Aggregate all the exported modules in a given src/platform directory into a file called

src/platform/{directory}/exportsFile.js, then re-export them from this file; we then add an alias, "./" , for the file in "exports":

"exports": {
  "./": "./exportsFile.js",
  "./someModule": "./path/to/some/module.js"
}
CODE

This aggregation gives VFS engineers a shorter way to import modules in their applications, especially if they are using many functions from different places in the package, e.g.:

import { someModule } from "@department-of-veterans-affairs/platform-{directory}"
CODE

as opposed to

import { someModule } from "@department-of-veterans-affairs/platform-{directory}/path/to/some/module"
CODE

Watch out for naming collisions among the different exports of a src/platform directory (e.g. two modules might export a function with the same name). Use your best judgment in resolving these conflicts by choosing alternate names or by including part of the path to the module in the alias.

3. Eslint will not resolve modules imported using Yarn Workspace syntax (e.g. "@department-of-veterans-affairs/platform-{directory}/someModule") unless an alias is added to the module-resolver plugin in the vets-website root level babel.config.json. So for every module listed in "exports" of platform/{directory}/package.json add an alias to the babel file, e.g.:

"module-resolver",
      {
        "root": "./src",
        "alias": {
          ...
          "@department-of-veterans-affairs/platform-forms/labels": "./src/platform/forms/address/data/labels.js",
...
CODE

If you add an alias to babel.config.json and are still getting an ESlint error that the module can’t be resolved try restarting VS Code.

Platform and VFS team engineers working with code in src/platform, if you have added new files and/or exports to your code do not neglect to curate your entry points (exports) and exportsFile.js.